User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 When composing an HTML message in Thunderbird 3.1 the font size and style in the message body changes after editing the subject. Reproducible: Always Steps to Reproduce: 1. Start composing a new HTML message 2. Start typing something in the message body 3. Edit the message's subject 4. Go back to the body pane and resume typing Actual Results: After editing the subject font size and style are diffent than before Expected Results: Font size should be the same Seems to be architecture independent, I was able to reproduce this bug in Fedora 13 (x86_64) and openSUSE 10.3 (x86).

While most of these editor complaints have been duped to bug 250539 We probably should be breaking this one out as a specific (different) bug See https://bugzilla.mozilla.org/show_bug.cgi?id=250539#c93 This appears to be a bug in "selection" rather than editor core. Martin, when you return to the editor window, try positioning the cursor before the last typed character, then resume your composition. Thinking about marking this new..suggestions welcome for the core component.

This seems to be reproducible using the Midas demo http://www.mozilla.org/editor/midasdemo/ So that would indicate core code. Working on STR.

STR: Start the midas demo and select a font Type a few characters in that font Remove focus on the edit window by using the dropdown for size, but just click out and not select anything. Attempt to refocus the edit window after the last typed character The cursor appears to be just to the right of the last typed character Resume typing. Result: Further composition results in the lose of the previously selected font. I believe this is because the cursor position is actually outside of the span tag. Thunderbird uses the font tag rather than span, but the same issue is seen when focus is returned to the edit panel, after moving focus elsewhere and attempting to continue the edit. This has caused untold grief and many duplicate bugs for Thunderbird HTML composition.

This appears to be a duplicate of the symptoms described in Bug 273622, the cause of which is explained in this comment in Bug 250539: https://bugzilla.mozilla.org/show_bug.cgi?id=250539#c93

Yes, this is indeed a problem with where the selection ends up being. Perhaps a good fix would be to inspect the selection at the beginning of nsHTMLEditRules::WillInsertText and adjust it if it's right after an inline element which is the last child of a block element...

(In reply to comment #6) > Yes, this is indeed a problem with where the selection ends up being. That's what I thought. You seem to be MUCH more familiar with the HTML structure in the editor, and with the code (and what might need to change). I'm more concerned with getting all the bugs which describe this problem into one place where the fix can be done. Bug 273622 seems to have the most accurate description, but that's been DUP'd to Bug 203810 -- which I'm not sure is appropriate; I can't tell by reading the description in Bug 203810, or by looking at the proposed patch (now outdated, I'm sure). I'd like your input into whether this bug should also be DUP'd to Bug 203810, or whether Bug 273622 should be reopened and this bug DUP'd to Bug 273622; you certainly seem more qualified to make that determination than I!

Bug 203810 doesn't have anything to do with this bug. Bug 273622 (or part of it) might be a dupe of this bug, but it's not worth fiddling with it after all this time. Let's just keep this bug open to track the issue at hand.

If this bug references change of size of html font size while typing. Then it applies to SM2.0.x as well. Has every since SM 2 has existed. what happens is you type a word or sentence and pause for a few seconds, the start typing again. Font will always resize to original size designed in SM2 even if you have default set to a larger size. And will even happen if you pause in the middle of a word.

(In reply to comment #9) > If this bug references change of size of html font size while typing. [...] No, it doesn't (see the "Summary" and the Steps to Reproduce).

I can use those steps to reproduce in SM2.0.2

sorry Version 2.0.6 not 2.0.2

Bug 677046 (which I submitted) was much more specific than what I read above as to how to replicate this intermittent bug, but it got discarded. 1. Hit 'Reply' to any e-mail. The bug doesn't occur in a fresh e-mail. 2. Type the following (without the indent): the quick fox jumped 3. Using the mouse, place the cursor before the 'f' of 'fox' and start typing 'brown ' (without the apostrophes) 4. Using the mouse, place the cursor after 'jumped' 5. start typing a space plus: over the lazy dog You should find that 'over the lazy dog' is in a reduced font.

(In reply to Ehsan Akhgari [:ehsan] from comment #6) > Yes, this is indeed a problem with where the selection ends up being. > > Perhaps a good fix would be to inspect the selection at the beginning of > nsHTMLEditRules::WillInsertText and adjust it if it's right after an inline > element which is the last child of a block element... On the second thought, this is just a dupe of bug 250539.

I won't quibble about the duping to bug 250539, but this is easily reproducible using the midas demo, and is symptomatic of loosing the selected font. Simple steps to reproduce using the midas demo: Select a font Type in several words Use your mouse to position the caret to the first word by left click Make some changes there Now attempt to reposition the cursor at the end of the line via mouse left click Result: You are outside the span, and your selected font does not apply. Note: After editing the 1st word, if you move the cursor to the right via the right arrow key you are good to go.(It's only the mouse repositioning that causes the problem) I don't see how this can be the desired behavior, even for the midas demo. For Thunderbird message composition, I think that mouse left click to reposition the cursor would be the most common case.

*Please* fix these sorts of bugs, Thunderbird team. I have to abandon the composition of many e-mails because of this sort of problem (and indeed I filed a bug myself on that, though, as usual - my fault or the bugtrackers? - I cannot locate that other bug report).