I'm filing this under thunderbird, but I'm sure it's a core editor issue. It's a common practice to break a list in html compose by hitting enter (cr) on an open entry. Bug 590640 fixed that issue. Bug 832025 seems to have regressed that fix. Steps: open an html composition insert a list and enter several terms use "enter" to break the list type in some more text prior to the checkin for bug 832025 the resulting html would be: <ul> <li><font size="-1"><font face="Arial">one</font></font></li> <li><font size="-1"><font face="Arial"><font size="-1">two</font></font></font></li> </ul> <p><br> <font size="-1"><font face="Arial">three<br> <br> </font></font></p> after the checkin: <ul> <li><font size="-1"><font face="Arial">one</font></font></li> <li><font size="-1"><font face="Arial"><font size="-1">two</font></font></font></li> </ul> <p>three<br> <br> </p> Obviously, the default font was not preserved. regression range: works:20130119030413 fails:20130121030413 There was no 20130120 build.

That bug fits the regression range; the patch merely added ClearCachedStyles() in two locations, so apparently that's causing the font to get flushed too... So, reading the description of bug 832025, the intention is that the Enter key is supposed to return to the default "Body Text" style when coming, e.g., from some header. I'd agree that this is intuitive for headings, but not for lists or other styles like Preformat, but maybe I'm missing something.

(In reply to rsx11m from comment #1) > That bug fits the regression range; the patch merely added > ClearCachedStyles() in two locations, so apparently that's causing the font > to get flushed too... > > So, reading the description of bug 832025, the intention is that the Enter > key is supposed to return to the default "Body Text" style when coming, > e.g., from some header. I'd agree that this is intuitive for headings, but > not for lists or other styles like Preformat, but maybe I'm missing > something. D'OH, I forgot font size in TB, yes the regression comes from bug 832025 and I fully accept that responsability. The trivial fix is to remove the second part of the patch from ReturnInListItem and get rid of the corresponding test. Anyway, I am going to attach here a backout fix. We probably need a way here of clearing font STYLE information (weight, slant, ...) but preserve general font info (size, family). Will spin off a new bug when I have spare cycles.

Just a backout patch for the part of fix for bug 832025 responsible for the current regression. Feel free to test/check-in, I'm not in a position to do it right now.

Comment on attachment 705282 [details] [diff] [review] fix Thanks!

verified fixed in TB build 20130125030443