User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Steps to reproduce: 1) Compose a new mail and type several lines of text into the main body of the mail. 2) Highlight all of the new text in the compose window. 3) Select Format->Size and increase the size to extra large. 4) Now (realising you want to add some more text) click in the middle of the text area and type in new text, and edit some of the text already there. 5) Nothing seems wrong at this stage but if the mail is sent then sometimes it seems to be fine in the copy that is actually sent, as confirmed by what appears in the copy in the Sent folder, but sometimes the font size is broken into sections of different sizes despite it all looking uniform at the point the Send button is about to be clicked. This seems to have been the case for some time. Actual results: Sometimes the font size is broken into sections of different sizes despite it all looking uniform at the point the Send button is about to be clicked Expected results: Font size should have been changed uniformly across all of the text that had been highlighted.

version Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a2 ID:20120810042011

Have had the changing font problem for years. My experience has been the font goes to a smaller size. Unpredictable when it will happen but simply pausing for a short time when composing a message in Thunderbird will often cause it when you resume typing. You can then go back, highlight the problem text change to what you intended and the message. When you then receive a response the effected text is back to the previous size. Strange, amateur coding.

I have been testing with version Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20120813 Thunderbird/16.0a2 ID:20120813042011 but not had a recurrence. I will keep testing over the coming days and report further in due course.

Still a problem, but I've found a workaround. When the fonts change while composing in Thunderbird stop, change to desired/correct size, SAVE, before sending. I've been sending a BCC to another account and the fonts maintain the desired size. If you don't SAVE before sending then they often show up at the other end as the changed size even after you had changed it to desired size before sending, but the use of a SAVE before sending seems to keep the desired size both going and on replys. Others experince?

It may be a workaround but not really user acceptable - I am using 17a2 and what I do is to type a text and wait until I have finished before hightlighting all of the text in the compose window and choosing a font size - that seems to have been consistent and works fine - previously if I made changes to the text after doing this then the text can be inconsistent size after sending. I am still unclear which versions of Thunderbird have the current patch in?

There still seems to be a font size consistency problem in v18a2 as well. I also tested the font issue by simply typing a long reply to an incoming email, and during that process going back in the text to change some of the words - after typing about two pages I noticed that the UI was showing missing characters and red squiggly lines at various places in the composed text. Sending at that point gave several sections of missing text and some corrupted text (words that had missing letters and some jumbled apparently at random). I get compose font issues very regularly although much of the time I can highlight the entire composed text and use Format->Size and select a font size which then fixes the highlighted text. However simply typing, including going back to edit text, often gives faulty display of the text once a page or so has been written. So there are still serious issues making composing html emails frustrating at best, and presumably not impressing too many of the users who comes across this bug regularly.

OK I did a test which seems to throw up the inconsistent font issue is a totally reproducible way - and the test is very simple indeed. I am using version 18a2 linux 64 bit version from 4th November but this test can be applied to any version that other testers following this bug can also try. The test is as follows: 1) Click "Write" to begin composing a new mail. My default font is set as medium, and sans-serif. 2) Now type direct into the main text box "This is a test " - 3) Now highlight the text you have just entered with the mouse and right click and copy. 4) With the cursor set at just after the last space in the text entered now right click and select "Paste without Formatting" The result is that the two phrases which should be identical are now of different font size. I will attach a screenshot in a sec showing the two different fonts in this text as highlighted.

By the way I use a simple html signature file - but I don't know if that makes any difference. Also the box showing the font changes from sans-serif to "mixed" as soon as I highlight the combined text in the test from comment #7

There is a bug report similar to this one at: https://bugzilla.mozilla.org/show_bug.cgi?id=203810

(In reply to Neville Hillyer from comment #10) > There is a bug report similar to this one at: > > https://bugzilla.mozilla.org/show_bug.cgi?id=203810 That is a similar bug that existed because of a whitespace bug in Editor which has been fixed.

I reverted to an older version because of this problem (which I initially described in bug 802190). Version 15.0.1 does not have this problem (for me at least). Would it help if we pinpointed at which version exactly the problem was introduced?

Mike, the steps you show in comment 7 are causing the manifestation of this version of the bug(s?) because at step 4, you moved the cursor back to the end of the previous text. As I have stated in other bug threads, this will change the typing point to be AFTER the hidden [/font] html tag even though it appears as you look at it in the typing space to be right after the last text character; in the html, it is not...it's now after the tag--thus invoking the default font rather than the specified font (unless for some reason you are still inside some other font specification for a div or span, etc--then you would revert to THAT font rather than default).

I guess it is another bug than mine after all then. But maybe-the-one: even though that is probably indeed the reason of the bug, it is NOT what should happen. The best way to fix this is as follows: when the cursor appears at the end of a line, for ANY reason (click on the right of it, using arrow-left on the line below it,...), the cursor should in reality be placed on the left of any closing tags present there. With a simple resursive method: if you see a closing tag at the end, move the cursor to the left of it; if you still see a closing tag then, move to the left of it again, etc. If however there is a space or an opening tag or anything else at the end of the line, just leave the cursor there. Something similar should happen at the start of a line: if the first thing on a line is an opening tag, put the cursor after that, until you don't have an opening tag on the cursor position anymore. All that said though, I can't reproduce this problem in Thunderbird 15.0.1. Perhaps this issue was (re?)introduced in version 16 then. The only similar thing I can reproduce is if I "select all" and then delete: then the font is lost. I believe the default font should be put back in this sort of case (i.e. if a message is reduced to nothing, or just a <br>).

Actually, "this sort of case" (at the end of my previou post) should rather be: as soon as the first opening tags in the message are removed. The main point is simply that one should never end up with an unstyled font; the default font should always be ... the default. But I truly believe the team should seriously consider whether integrating another HTML editor would not make more sense, as it may well solve many more bugs at the same time.

Using TB 17.0 on Windows 7 SP1 64-bit. Just upgraded from a very old version. This annoying bug has apparently been around since 2003! When I compose a message and use the backspace key TB throws in a font tag to change the size, so when I view the HTML of the message I get text that looks like this: <br><br>If you <font size="+1">need complex <font size="+1">conditions like Answer = A or <font size="+1">D, then <font size="+1">it gets complicated. Page <font size="+1">Conditions</font> </font> </font> </font> </font> need to be in separate Groups to be evaluated with OR<font size="+1">; conditions in the same <font size="+1">G</font> roup</font> are evaluated w<font size="+1">ith AND</font> , so both conditions must be met for the condition to be true. The Skip To option <font size="+1">can be confus<font size="+1">ing too. You may need to experi<font size="+1">ment to get it to work like you want.</font> </font> </font>

Confirm the previous post. Using the backspace key inserts additional font tags every time it is used... <body style="font-family: Calibri; font-size: 19px;" bgcolor="#FFFFFF" text="#990000"><font face="Calibri">##############BSSP<font face="Calibri">xxxxxxxxxxxxxxxxxx<font face="Calibri">yyyyy<font face="Calibri">zzzzzzzz</font></font></font></font></body>

I'm not sure the bug has "been around since 2003", though. As mentioned before, I downgraded to 15.0.1, and this behaviour no longer appears for me. See below: I hit backspace every time I switched to another letter. In version 16 or later, it would have produced the redundant tags as described above. <font size="-1"><font face="Verdana">ccccccccdddddd[text inserted]ddddddeeeeeefffff</font></font> I.e., as it should be. So if the bug was really present in 2003, it has been solved since, but reintroduced somewhere around the time version 16 was released.

(In reply to bugzilla from comment #18) > I'm not sure the bug has "been around since 2003", though. As mentioned > before, I downgraded to 15.0.1, and this behaviour no longer appears for me. I just tried rolling back to 15.0.1 and got the following results: Date: Tue, 27 Nov 2012 11:20:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <font face="Tahoma">I just want to test the new functionality of </font>Thunderbird 15.0.1. Any better or not?<br> <br> Paul<br> Everything from 'Thunderbird' on has picked up the font information (smaller size, different font) from the message I was replying to. Obviously, that's not what I'm after... So something is still lurking in 15.0.1. Or is it in my profile somewhere?! Because I uninstalled 17.0 and installed 15.0.1, but I'm using the same profile as before.

Well, that's a different bug: what I was refering to was tags being repeated when they're not needed, but what you are reporting is a tag ending too soon. What I mean: <font>Hell<font>o, here are t<font>oo many tags<font>.</font></font></font></font> ==> the formatting is repeated many times, resulting in redundant tags. Sometimes it does cause font problems, butthey are difficult to reproduce. What you mean: <font>Hello, here are t</font>oo many tags. ==> the formatting is not repeated, and the major problem is that the extra text is put after, instead of before, the closing tag. Looks to me like the second (your) bug was solved by a patch that (re)introduced the first bug (mine).

(In reply to bugzilla from comment #20) > Well, that's a different bug: what I was refering to was tags being repeated > when they're not needed, but what you are reporting is a tag ending too > soon. > > What I mean: <font>Hell<font>o, here are t<font>oo many > tags<font>.</font></font></font></font> > ==> the formatting is repeated many times, resulting in redundant tags. > Sometimes it does cause font problems, butthey are difficult to reproduce. > > What you mean: <font>Hello, here are t</font>oo many tags. > ==> the formatting is not repeated, and the major problem is that the extra > text is put after, instead of before, the closing tag. > > Looks to me like the second (your) bug was solved by a patch that > (re)introduced the first bug (mine). Well, colour me confused... I was commenting on another bug, but it seemed that we were pointed here. Maybe I lost track of which was which (entirely possible!) All I want is my messages to be sent like they look before I send them. None of these (software introduced) 'changes' appear until it goes to the recipient. If I type in a particular font at a particular size--and don't change them--I want them to stay that way when I click Send.

I absolutely agree. Here's a tip: do "select all", "cut", and "paste" (a.k.a. control-axv). It's rather cumbersome to do this with every single email you compose, but as far as I've tried, this does reveal any erroneous formatting that has occured. In another bug, I described that as "What I See is not What I Get". In other words, as it stands now, the Thunderbird composer is NOT a WYSIWYG editor, even though everyone is expecting it to be (including the developers, I'm sure).

(In reply to bugzilla from comment #20) > Well, that's a different bug: what I was refering to was tags being repeated > when they're not needed, but what you are reporting is a tag ending too > soon. > > What I mean: <font>Hell<font>o, here are t<font>oo many > tags<font>.</font></font></font></font> > ==> the formatting is repeated many times, resulting in redundant tags. > Sometimes it does cause font problems, butthey are difficult to reproduce. [...] That's bug 812638

bug 812638 was created less than 2 weeks ago... that/this issue has been around since much longer, and has been mentioned in various bugs. I don't really understand why that new bug has been assigned to someone and been marked as 'NEW' while this one - 15 weeks old as opposed to 2 - is still 'UNCONFIRMED'. In any case though, good thing someone's looking at it, because if that one is fixed, there's a chance the other related bugs are also solved (if only partly). Related bugs (in my opinion) are among others bug 798868 and bug 802190. I stand by my suggestion to integrate an other existing HTML editor (Kompozer, CKEditor,...), rather than fixing the countless small bugs in the current one. There are excellent editors out there, and even though I realise integrating a new editor would take considerable work, I am convinced it would still be faster and more efficient than handling the long list of small bugs.

This has been here for YEARS...if you believe the bug is "fonts change when they should not." Yes, there must be hundreds of versions of "steps to reproduce," but the end result is always the same--fonts not what they are supposed to be. A few of the volunteer developers have written about this is the past in other threads of SOME version of this bug. They have said the composer code is in C and not many current devs are proficient in that language. Worse, the code was modified by many different people over the years, is horribly documented, and thus is almost impossible to work on. Assuming that is the case, I concur with the idea of at least LOOKING AT replacing the composer with something already proven. I know it would not be just a drop-it-in situation, but it probably is the path of least resistance. Somehow, the community supporting Thunderbird needs to collaborate long enough to internally discuss this possibility. It also would be nice to clue in us users with status reports regularly.

(In reply to maybe-the-one from comment #25) > This has been here for YEARS...if you believe the bug is "fonts change when > they should not." Yes, there must be hundreds of versions of "steps to > reproduce," but the end result is always the same--fonts not what they are > supposed to be. > > A few of the volunteer developers have written about this is the past in > other threads of SOME version of this bug. They have said the composer code > is in C and not many current devs are proficient in that language. Worse, > the code was modified by many different people over the years, is horribly > documented, and thus is almost impossible to work on. As a user, the various font-changing bugs have driven me crazy and are causing me to consider abandoning Thunderbird. So I agree, if this editor seems too difficult to fix due to reasons like the above, then replace it.

Does it require an RFE to request that the editor should be replaced by one that actually works?

I've bookmarked 17 bug numbers dealing with font problems. Want the list?

I say post it. I'll add my vote for any that I haven't already voted up.

Here's the list: Bugzilla bugs dealing with Font problems: (Note: Some of these bugs are marked "Resolved"; a number of the bugs are marked duplicates of others listed. I've added a few titles when the bug doesn't seem to involve actual unexpected font changes or inserted tags. 98763 Mail toolbar doesn't display current font size 203810 250539 308437 Add a combobox to set absolute font size to the composition toolbar 480647 execCommand('fontSize') doesn't change font size if content font size is specified in css 536613 590640 601658 606668 617878 There is no way to control the default font in a HTML signature 756984 757371 782215 798868 799893 802190 812638

Hey Aryeh - does this sound like an Editor bug to you? If so, do you think you might have some cycles to poke at it?

It sounds like it's almost surely a bug in either editor or selection code, yes. If someone can give me clear steps to reproduce in Firefox, e.g. in the Midas demo: http://www-archive.mozilla.org/editor/midasdemo/ then I can take a look. I suspect different people here are talking about entirely different bugs. Comment 16 definitely looks like bug 812638. Comment 7's steps to reproduce look good and probably identify a real bug, but don't work in Firefox as-is, because there's no "Paste without formatting" context menu option. Comment 13 is very possibly true, and comment 14 is exactly right: we should ideally make the caret always stick to adjacent text nodes and not fall in between two tags. Be warned that even if the bug is identified more clearly, it might not be worth our while to accept a fix, as long as we have no one consistently available to address potential regressions in a timely fashion.

Hello, this is not a bug solver comment but a simple user (with no tech experience) comment. Sorry for that. With respect to the status of Bug 782215 I can say that what it is reported in the Description field exactly happens in Windows since (I can't recall precisely) probably even before August 2012. The net result is that Thunderbird (I am now using 17.0.5 on Windows) messages may look really unprofessional. Don't get me wrong: I love each and every single bit from Mozilla. That's why I am posting my feedback: hoping this bug can be resolved asap (even if I am aware of the priority changes applied by Mozilla for Thunderbird in terms of development). My "feeling" is that spell checking might also be involved. As far as my experience is concerned Thunderbird spell checking has also had unresolved problems since quite a while: sometimes, after having typed a correct word, Thunderbird "brakes" the correct word by underlining all the letters except the first one. In order not to have this annoying incorrect underlining I switch to another language spell checking and then back to previous one and this "restores" the "normal" behaviour. Some times the sections with different font sizes (and maybe also different font type? I haven't checked) reported in the Description field of this bug coincide with the points where the "braking and subsequent incorrect underlining" happens.

Change <the points where the "braking and subsequent incorrect underlining" happens> with <the points where the "breaking and subsequent incorrect underlining" happens>

@Aryeh: I went to the Midas demo, and pasted an example of text that was changed out from under my current edit by mousing out of the editor and then back in. I'm also attaching a screencast of the behavior and a screenshot of the Midas demo display. <font face="Verdana">In my profile I find the "Local folder username,"&nbsp; with a description</font> of "the font size is not correct."<br> <div class="moz-signature">-- <br> <img alt="G. Richard Bellamy" src="http://www.terradatum.com/metrics/images/rbellamy_sig.png"> </div>

My problem is when I copy a paste some text from another source into my email. That pasted text may be smaller or larger that the font I've been using, but when I want to make everything uniform when I'm done, I can't do it. Why not have a simple absolute font size selector. Thank you for T-Bird. It saved me from W-Live.

Font changes occur on new and reply composition. Cut and Paste seems to exacerbate the problem, moving a sentence from the end of a paragraph to the middle or beginning. Full message source attached in next reply.

This is the actual message source ... names hopefully changed to protect the innocent. Some of the header was stripped, as well.

Comment on attachment 8360888 [details] BadFont.txt Oh - bug remains in build 24.2.0 ... Unfortunately, it is now disrupting communications in a way that I now am looking for alternatives; even Outlook. Yuck.

Also - seems to be related to this panose-1 font (or perhaps the mso feature). Error console reports below. The panose-1 error comes up during auto-spell-check just before sending. No - I don't have a Panose-1 font. Timestamp: 1/15/2014 10:55:33 PM Warning: Unknown descriptor 'panose-1' in @font-face rule. Skipped to next declaration. Source File: mailbox:///C:/Users/Me/AppData/Roaming/Thunderbird/Profiles/xook8fm7.default/Mail/mail.me/Inbox?number=334168679 Line: 17, Column: 9 Source Code: panose-1:2 11 6 4 3 5 4 4 2 4;} Timestamp: 1/15/2014 10:55:33 PM Warning: Unknown property 'mso-style-priority'. Declaration dropped. Source File: mailbox:///C:/Users/Me/AppData/Roaming/Thunderbird/Profiles/xook8fm7.default/Mail/mail.me.net/Inbox?number=334168679 Line: 36, Column: 20 Source Code: {mso-style-priority:99;

I have this problem in 24.2.0 and it is driving me potty. It makes TB seem amateur compared to Outlook which I used years ago. I will have to look for an alternative if this continues.

This is still happening as of 24.6.0 - At times it seems to be also related to email that has been received from iPhones where the iPhone inserts characters not recognized by Windows (not true UNICODE). So an apostrophe ' or odd space shows up as a diamond ? symbol. Not sure where all the -C2=20 are coming from, but they look like malformed Unicode. Fonts change when similar characters appear in email. and $50.= =C2=20 I'm free all Translates into: $50.� I'm free all

In addition to the bugs listed at Comment 30 you can also add at the very least bug 677046. Thunderbird changing fonts gets plenty of hits via Google: https://www.google.com.au/search?q=thunderbird+changing+font+while+typing&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a&channel=sb&gfe_rd=cr&ei=ScPqU7fLEIzN8gf8zYHICQ For me all these editing issues with fonts sizes increasing mid-message and signatures not displaying and/or printing properly (fixed Bug report 919151) all commenced with an upgrade from TB17.0.8 to TB24.

There are bug reports along the lines of this one *all over the bugtracker* (including these ones: ##886146. 933409, 1209714). Moreover, the functionality at issue - getting fonts to be consistent and user-controllable - is *basic*. For those two reasons I submit that, unless Thunderbird wants to continue to lose market share, someone actually **fix this**, please. How hard can it be? I am almost ready to give up on Thunderbird - because, primarily, of this problem.