User Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121024073032 Steps to reproduce: Thunderbird is inserting random and incorrect <font size="3"> tags in the middle of words throughout my email message. I did some experimenting and I can see this strange behavior in Thunderbird 16 that wasn't in Thunderbird 15. This appears to be happening on all platforms, but I am running Windows XP SP3 and Thunderbird 16.0.2. Steps to reproduce: 1. Create a new HTML message and enter several lines of text. 2. Highlight all of the lines of your email text with CTRL-A. 3. Click on Toolbar Insert > HTML. 4. Add a <font size=3> at the very beginning of your text and </font> at the very end of all your text, if not already there, and save the change. 5. Go back to your email compose window and insert more text in the middle of your email, enter some backspaces, pause, add some text, change some text, backspace and delete some text, move the cursor around the text, and update some text. 6. Again do a CTRL-A and highlight all your lines 7. Go to Toolbar Insert > HTML. 8. What I then see is that Thunderbird has added multiple incorrect instances of the <font size=3> throughout my email message, often times breaking a word with the <font size=3>. Actual results: These are my results: In my regular email HTML compose window, I see this text: This is a test line. After a CTRL-A to select all text, in the Insert > HTML view, I see this: <font size="3">Thi<font size="3">s is a t<font size="3">est li<font size="3">ne.</font></font></font></font> Expected results: There is no need to add all the extraneous <font size="3"> tags, especially not adding them in the middle of words.

This issue with <font size="3"> being incorrectly generated and inserted within words caused an issue with spell check marking the words as incorrect. As cross reference information, Bug 790475 - Spell checking broken was created for the spell check issue.

This bug is "confirmed" since without it, bug 790475 would probably never have been found. I'm not sure whether it belongs in "Thunderbird :: Message Compose Window", in "MailNews Core :: Composition", or even in "Core :: Editor". Wayne, what do you think?

I've noticed some other buggy behaviour in TB editor recently, which could well be related. When you copy and paste a word to the end of a line, it inserts a line break before the word. Steps to reproduce: (1) Compose new email. (2) Type "this is a test" (3) Select "is" (or indeed any part of the text) (4) Ctrl-C (5) Position cursor at end of line (6) Ctrl-V (7) The word "is" appears on the next line, not at the end of the line (8) Subsequently repeating steps 5&6 will however paste on the end of the line Not, this only occurs when pasting with formatting. It's fine using Ctrl-Shift-V.

Further to this, I just looked at the HTML after typing "this is a test" on one line, and there's a <br> tag added on the end .. so this would explain the behaviour I'm seeing. <font face="Helvetica, Arial, sans-serif">this is a test<br> </font> Not so sure now this is the same problem as the other bug. Should I move this to a new bug report?

(In reply to Seb from comment #4) > one line, and there's a <br> tag added on the end ... > Not so sure now this is the same problem as the other bug. Should I move > this to a new bug report? Perhaps check out existing copy/paste bugs first, there are some including copying eol problems.

This looks like the regression pointed to here: https://bugzilla.mozilla.org/show_bug.cgi?id=757371#c3 Specifically, this comment 15272 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/imptests/editing/conformancetest/test_runtest.html | [["fontsize","4"]] "<font size=4>foo[bar]baz</font>" compare innerHTML; assert_equals: Unexpected innerHTML (after normalizing inline style) expected "<font size=\"4\">foobarbaz</font>" but got "<font size=\"4\">foo<font size=\"4\">bar</font>baz</font>" Set blocking to the bug where the regression was introduced. Aryeh indicates this might be fixed in bug 747889 so perhaps we should dup to that bug.

Very easy to reproduce in the Midas Demo by backspacing into a word to correct. Resulting HTML <font size="3"><font face="Arial">the quick bro<font size="3">wn</font> fox<br></font></font>

It seems to depend on non-default font usage when an e-mail is composed. I.e.: when the TB default font is configured (and therefore used when an e-mail is being composed), there is no additional <font> info added. While when a non-default font is configured, the configured font size is superfluously added throughout the e-mail, sometimes within a word, which for the spell-checker splits the word (see bug 790475 "Spell checking broken", or its multiple copies). E.g., I have a non-default font ("Helvetica, Arial"), as well as a non default size ("small", which seems to correspond to <font size="-1">) configured in my TB configuration. When I compose an e-mail, <font size="-1"> is being added superfluously throughout the e-mail. While when I reset the TB font configuration to its default, no additional <font> info is added to the e-mail. So, the reason for the difference between my added <font size="-1"> above and the bug submitters <font size="3"> seems to be the fact that I have the <font size="-1"> configured in TB, while the bug submitter set <font size="3"> in his well described bug reproduction steps. While both use a non-default font (size) for the bug to show itself. ------------------ Here is my TB configuration (from the "Help" -> "Information..." menu, German version): Allgemeine Informationen Name: Thunderbird Version: 16.0.2 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 Profilordner: Ordner anzeigen (Lokaler Datenträger) Build-ID der Anwendung: 20121026120400 Aktivierte Plugins: about:plugins Build-Konfiguration: about:buildconfig Absturzberichte: about:crashes Speicherverwendung: about:memory E-Mail- und Newsgruppen-Konten account1: INCOMING: account1, , (imap) imap.gmx.net:993, SSL, passwordCleartext OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, true OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, false OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, false OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, false OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, false OUTGOING: mail.gmx.net:465, SSL, passwordCleartext, false account2: INCOMING: account2, , (none) Local Folders, plain, passwordCleartext account3: INCOMING: account3, , (rss) Feeds, plain, passwordCleartext Erweiterungen Highlighter, 0.6.5, true, andre.rodier-highlighter@gmailcom Russian spellchecking dictionary, 0.4.4.1, true, ru@dictionaries.addons.mozilla.org United States English Spellchecker, 6.0, true, en-US@dictionaries.addons.mozilla.org Wörterbuch Deutsch (de-DE), Hunspell-unterstützt, 20120628, true, de_DE@dicts.j3e.de Wichtige modifizierte Einstellungen Name: Wert accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 1048576 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size_cached_value: 737280 browser.zoom.full: true extensions.lastAppVersion: 16.0.2 gfx.blacklist.suggested-driver-version: 6.14.10.5260 mail.openMessageBehavior.version: 1 mailnews.database.global.datastore.id: 19d79eb7-7865-4d82-a29e-3cbf82d5838 network.cookie.cookieBehavior: 2 network.cookie.prefsMigrated: true places.database.lastMaintenance: 1353266760 places.history.expiration.transient_current_max_pages: 26585 places.history.expiration.transient_optimal_database_size: 42534666 print.print_printer: PDFCreator print.printer_PDFCreator.print_bgcolor: false print.printer_PDFCreator.print_bgimages: false print.printer_PDFCreator.print_command: print.printer_PDFCreator.print_downloadfonts: false print.printer_PDFCreator.print_edge_bottom: 0 print.printer_PDFCreator.print_edge_left: 0 print.printer_PDFCreator.print_edge_right: 0 print.printer_PDFCreator.print_edge_top: 0 print.printer_PDFCreator.print_evenpages: true print.printer_PDFCreator.print_footercenter: print.printer_PDFCreator.print_footerleft: &PT print.printer_PDFCreator.print_footerright: &D print.printer_PDFCreator.print_headercenter: print.printer_PDFCreator.print_headerleft: &T print.printer_PDFCreator.print_headerright: &U print.printer_PDFCreator.print_in_color: true print.printer_PDFCreator.print_margin_bottom: 0.393750011920929 print.printer_PDFCreator.print_margin_left: 0.5 print.printer_PDFCreator.print_margin_right: 0.5 print.printer_PDFCreator.print_margin_top: 0.393750011920929 print.printer_PDFCreator.print_oddpages: true print.printer_PDFCreator.print_orientation: 0 print.printer_PDFCreator.print_page_delay: 50 print.printer_PDFCreator.print_pagedelay: 500 print.printer_PDFCreator.print_paper_data: 9 print.printer_PDFCreator.print_paper_height: 11,00 print.printer_PDFCreator.print_paper_size_type: 0 print.printer_PDFCreator.print_paper_size_unit: 1 print.printer_PDFCreator.print_paper_width: 8,50 print.printer_PDFCreator.print_reversed: false print.printer_PDFCreator.print_scaling: 1,00 print.printer_PDFCreator.print_shrink_to_fit: true print.printer_PDFCreator.print_to_file: false print.printer_PDFCreator.print_unwriteable_margin_bottom: 0 print.printer_PDFCreator.print_unwriteable_margin_left: 0 print.printer_PDFCreator.print_unwriteable_margin_right: 0 print.printer_PDFCreator.print_unwriteable_margin_top: 0 security.OCSP.require: true security.ssl.renego_unrestricted_hosts: mail.gmx.net security.ssl.require_safe_negotiation: true Grafik Karten-Beschreibung: Intel(R) Graphics Media Accelerator 3150 Vendor-ID: 8086 Geräte-ID: a011 Karten-RAM: Unknown Karten-Treiber: igxprd32 Treiber-Version: 6.14.10.5134 Treiber-Datum: 9-24-2009 WebGL-Renderer: Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 6.14.10.5260 zu aktualisieren. GPU-beschleunigte Fenster: 0/4. Wurde auf Grund Ihrer Grafiktreiberversion blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 6.14.10.5260 zu aktualisieren.

(In reply to Joe Sabash from comment #6) > This looks like the regression pointed to here: > https://bugzilla.mozilla.org/show_bug.cgi?id=757371#c3 > Specifically, this comment > 15272 ERROR TEST-UNEXPECTED-FAIL | > /tests/dom/imptests/editing/conformancetest/test_runtest.html | > [["fontsize","4"]] "<font size=4>foo[bar]baz</font>" compare innerHTML; > assert_equals: Unexpected innerHTML (after normalizing inline style) > expected "<font size=\"4\">foobarbaz</font>" but got "<font > size=\"4\">foo<font size=\"4\">bar</font>baz</font>" > > Set blocking to the bug where the regression was introduced. That might or might not be related. Bug 757371 was fixed in 15, so if this occurred in 16 it probably isn't the same exact bug. > Aryeh indicates this might be fixed in bug 747889 so perhaps we should dup > to that bug. Bug 747889 is the bug to fix it "properly". Actually, I have my doubts now about whether that's the right idea -- trying to shoehorn CSS font sizes into a command that really only handles HTML <font size> is probably a bad idea. Probably dropping any kind of CSS support for fontSize is a better idea. In any event, this is definitely a separate bug that should be tracked separately, not a dupe.

Same issue here. Sent an email in normal HTML to an address that only has a text-based client. The returned email showed the raw HTML code and I could see extra <font> tags in the middle of words, etc. I found this bug report from the spellcheck as you type bug report since TB 16.x #790475 Thunderbird 16.0.2

(In reply to Joe Smith from comment #8) > It seems to depend on non-default font usage when an e-mail is composed. Here is the missing step-by-step reproduction procedure: 1. Configure the font in "HTML Options" of TB configuration (menu "Extras"...) to "Helvetica, Arial", size "small" (corresponds to <font size="-1">). 2. Compose an e-mail (a new one, or as reply to another one – its irrelevant). While typing, use the backspace key a few times to delete and re-type letters, then continue typing. 3. Save the composed e-mail to drafts, go to the drafts folder and view the source of the e-mail. (Or alternatively send the e-mail and then see the source of that e-mail in the sent e-mails folder.) Results: 3. The source will show <font size="-1"> at the positions where the backspace was used (in the middle of words or not). (NOK – the addition of <font size="-1"> is superfluous). The issue does not occur when one resets the font to its default ("Variable", "middle") on step 1, using the "reset to default" button. The above issue could be seen when the spell checker suddenly marked a part of the word (instead of e.g. the whole word) as incorrect and one then saw in the e-mail source that that word had been split by <font size="-1">. That behavior came with TB version 16 or 16.0.1. and was reported by many people – see bug 790475 “Spell checking broken”, with its many copies. I had an impression that there were also cases when the above <font size="-1"> was added spontaneously, without usage of the backspace key – i.e. simply while typing, or at a location where one waited awhile before continuing typing. But I cannot reproduce that right now, so that it were probably just cases when I didn't remember using the backspace key.

I've experience the partial word formatting problems when I use an HTML signature that sets a specific font using HTML. If I type within the text formatted by the signature, the words seemingly randomly show spelling errors on parts of words. I assume this is caused by font tags getting inserted mid-word as described by others here.

Fedora 17, using fixed font, bug still exists. If, after I see a partial word underlined, I use a <space><backspace> combination on the same line, the partial word underline goes away. If I don't, then the underline persists.

Continues to occur in Thunderbird release 17.0

Aryeh, can you please give this a shot?

My machine updated to Thunderbird 17 (Fedora 17 as well) yesterday. With all defaults, except that I use fixed font, I'm no longer having a problem.

I'm using Thunderbird 17, with a custom font, and can confirm this is still broken. When I check my Sent items, in places where I've used a backspace the font sometimes switches to Variable Width, changes size, or both. To be honest I've found that using a custom font has always been a bit broken. In earlier versions, if you pressed enter twice (after a list for example), the font would always revert to Variable Width. To get the same font to continue throughout the email I would have to start typing the next paragraph at the end of the last list item, then go back and put the carriage returns in. Even then, with the text in the custom font already being used, it would sometimes try reverting to Variable Width as the next character following (in terms of time, not placement) the carriage returns. In that instance, pressing backspace until you had deleted 1 of the custom font characters would then "reset" the system and start typing in the custom font normally. Ubuntu 12.10 x64

This is just a speculation, but this bug, as well as existence of following bugs: bug 606668 bug 799893 bug 617878 shows that there might be something wrong on architecture level: The font configuration in "HTML Options" of TB configuration (menu "Extras"...) does not seem to set the font application-wide. Instead, it seems that it is still possible for various functions to use the TB default font (“Variable width”, “middle”) instead of the one configured by the user. Either by still being able to access the TB default, or by using own in-function default. Anyway, the functionality responsible for this bug seems to “know” that a non-default font (size) has been configured, which it shouldn't know – the font configured in “HTML Options” should be used as if it were the TB default. Or does it point to some sort of a post-processor causing the bugs? (E.g. responsible for checking that all closing HTML statements exist, that no non-formatted text exist, etc.) In that it still uses the TB default. Note: The manual addition of <font size> by the bug reporter corresponds to setting a font size in “HTML Options”.

That's what I was wondering, it's seemed to me for a while now that TB will always tend towards using the default font setup, whether it's this bug report or the effects I described above from a previous version. I thought about posting before but my symptoms seemed so specific it was only after seeing this recent bug I realised the whole thing could be related. I should also add that in my setup I have also changed the font size to "small", so the size fluctuations I'm seeing are probably it tending back towards "normal" (although not consistently).

I was able to reproduce this using the steps provided above. Results (Thunderbird 17.0) I am writing to you about what's up. Spell check reproducing bug <font size="-1"><font face="Helvetica, Arial, sans-serif">Hi,<br> <br> <font size="-1"><font face="Helvetica, Arial, sans-serif">I am writ<font size="-1"><font face="Helvetica, Arial, sans-serif">ing to you abo<font size="-1"><font face="Helvetica, Arial, sans-serif">ut what's up. Spell check reproduc<font size="-1"><font face="Helvetica, Arial, sans-serif">ing bug</font></font></font></font></font></font></font></font><br> </font></font> Changing font to Arial. We'll see what happens <font size="-1">Chang<font size="-1">ing font to Ari<font size="-1">al<font size="-1">. We'll see w<font size="-1">hat happens</font></font></font></font><br> </font> Fixed width font. Does this work? I suppose I'll find out <font size="-1"><tt>Fixed width f<tt><font size="-1">ont<tt><font size="-1">. Does this wo<tt><font size="-1">rk?<tt><font size="-1"> I suppo<tt><font size="-1">se I'll find out</font></tt></font></tt><br> </font></tt></font></tt></font></tt></tt></font> Now some notes. After saving and editing again, the (supposedly) misspelled words are not underlined as they were when composing. When replying to an email, this issue has only occurred twice now for me (despite what's shown above), since updating to 17 but it happened while composing a new email or replying to one with 16.0.1 (or 2) every time. Please let me know if there's some other way for me to help.

Please also check bug 782215 which is probably related. It has been suggested in several related bugs that the best way to fix the editor issues, may be to integrate an other existing editor (either a Mozilla one or another open source one), rather than trying to fix the countless small bugs in this old baby. We realise that would be quite a project, but it would result in a much cleaner and long-lasting solution. Please, give this some serious thought.

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, then replace it. In one of the other font bug threads, one post notes: "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." If accurate, that lends a lot of weight to the argument to replace.

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

Most 3rd part editors are just wrapping the editing capabilities of the mozilla (platform) editor, no? :protz experimented with replacing it, but it did not work out will so far. (I think it's used for the conversation add-on quick replies though.)

Just an observation, and I'm not sure if this has been mentioned and, it most likely holds no significance, but hitting the space bar and then backspace before the first letter of the supposedly misspelled word removes the underlined characters.

Sorry I misspoke. The characters are not removed, the line below is.

Sorry if this is more of a support question, but are there any options to disable or change the default text editor? I'd be fine with composing in plain text.

Tools > Options > Composition > Spelling > uncheck "Enable spell check as you type" tick "Check spelling before sending" or right click Check Spelling. Good enough for now. Enjoy the rest of your weekend

This problem occurs in Seamonkey 2.14.1 as well. It was not present before in 2.12. It is a new problem that should be fixed, not by replacing the entire editor.

Depends how you look at it. If this was the only issue that the editor had, then of course it should be fixed and we'd be done with it. The problem is that it is not. Some sources suggest the reason for this is that it is difficult to fix bugs in it due to poor code documentation and a different programming language. Whatever the case, there are several open source editors that have none or almost none of the issues Thunderbird's Composer has. That is why some of us are suggesting to start up a project to integrate one of those editors, rather than fixing 1 Composer-editor bug per Thunderbird version, leaving many issues open (or introducing new ones) each time. But I fully understand that this would be a big project. If someone with authority can say that this will never happen, we can stop suggesting it and focus on the bugs to be solved...

Please also don't forget that the mail composer in Thunderbird is actually just a limited view on the more generic HTML composer in Seamonkey. In general it is not so easy to replace such a major piece of software with a rewrite or even something imported from another project without introducing more problems than fixes. Especially when looking at the problem from one direction only. In fact, when the (still regrettable IMHO) split from Mozilla into Firefox and Thunderbird occurred, and the Composer was orphaned, several projects were undertaken to isolate the composer into a third program. It wasn't a success.

One additional thing I have noticed is that when composing and the fonts get messed up there is usually also missing words and red underlines in the compose window in places it should not happen - however I have found that using the vertical slider to move to a different part of the compose area and back again usually fixes the on-screen view of the corrupted compose text - but this of course may be a very different bug than the issue of wrong html tags?

Afasics, this bug only occurs when using <font size="x"></font> with certain values of x as explained in reduced STR below. (From Bug 790475 Comment 94) (In reply to Mike Conley (:mconley) from bug 790475, comment #91) Otherwise, basically following your STR of bug 790475 comment 13 in Thunderbird reproduces this bug for me every time (both release & trunk), albeit only if using certain size values for deprecated font size attribute in <font size="x"></font> around the msg body (which is what we use when changing composition's default font size in preferences!), or around any word(s) inside msg body: STR 1 compose new HTML msg 2 in msg body, type misspelled word "I am testung " (sic! testung followed by one space) 3 Ctrl+A, Insert > HTML 4 add font tags around msg body HTML, then [Insert], like this: <font size="x">I am testung <br></font> ...where x must be between 1 and 6 (sic!), or between -3 and +3 (sic!); surprisingly, bug will *not* occur for - max values of font size attribute (7, +4) - invalid values of font size attribute (>7, or >+4, e.g. 8 or +5 etc.) - non-default font *face* attributes aka <font face="Calibri"></font> 5 hit backspace 4 times to erase "ung " 6 type "ing x" to make it "I am testing x" where x is any alphanumeric character 7 observe spell check marks on "testing" (red squiggly) 8 verify HTML source (Ctrl+A, Insert > HTML) Actual result 7 "ing" part of "testing" is marked as misspelled (red squiggly) - same symptoms as bug 790475 8 redundant font tags are wrongly added in source (emphasis stars added by me), this Bug 812638: <font size="x">I am test*<font size="x">*ing a*</font>*<br> </font> Expected result 7 "testing" is correctly spelled hence should not get marked misspelled in any way (same symptoms as bug 790475, currently titled "Spell checking is broken"!) 8 redundant font tags should not be added (this Bug 812638; imho this is a major bug which should be fixed immediately to stop that tag pollution)

(In reply to :Ehsan Akhgari from comment #15) > Aryeh, can you please give this a shot? Imho, this is a major bug which should be fixed asap (to complement existing "fix" for bug 790475), more so given precise STR and conditions listed in comment 33). * The HTML source of messages affected by this bug is total garbage, and massively inflates message size and network traffic for long messages with multiple retyped corrections. (See example below) * The consequent wrong behaviour of the spell checker makes this very visible even for unsuspecting users, and the number of bugs for this problem is on the increase. Example for HTML source inflation: This is how a simple short sentence... <font size="3">I am testung</font> ...is inflated after just a handful of retyped corrections ("I was testing"): <font style="color:darkblue;background-color:yellow;" face="Arial Rounded MT Bold" size="3">I <font size="3">wa<font size="3">s</font></font> test<font size="3"><font size="3">i<font size="3">n</font>g</font></font><br> </font> Imagine the potentially unlimited garbage users will get for a longer text with many corrections!

(In reply to Thomas D. from comment #34) > Example for HTML source inflation: > > This is how a simple short sentence... > <font size="3">I am testung</font> Interestingly, adding any other attributes to the original font markup... <font style="color:darkblue;background-color:yellow;" face="Arial Rounded MT Bold" size="3">I am testung</font> ...will *not* reproduce these attributes in the redundant font tags: > ...is inflated after just a handful of retyped corrections ("I was testing"): > > <font style="color:darkblue;background-color:yellow;" face="Arial > Rounded MT Bold" size="3">I <font size="3">wa<font size="3">s</font></font> > test<font size="3"><font size="3">i<font > size="3">n</font>g</font></font><br> > </font>

This bug can have serious implications when pasting in parts of link URLs For example: (1) Start a new message, in HTML compose mode (2) Type: www.web.com?id= 1234 (3) Cut "1234" and paste on the end of id= (4) The 1234 appears on the next line (which is in itself a bug) (5) Set the cursor before the 1234 and press backspace once to move it to where it should have appeared. (6) So the email content now looks like this: www.web.com?id=1234 (7) However, when sent, the 1234 is not included in the link. The HTML looks like this: <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <font face="Helvetica, Arial, sans-serif"><a class="moz-txt-link-abbreviated" href="http://www.web.com?id=">www.web.com?id=</a></font><font face="Helvetica, Arial, sans-serif"><font face="Helvetica, Arial, sans-serif">1234</font><br> <br> </font> </body> </html>

I don't have time to work on anything at the moment. It will be at or close to the top of my list for when I do, though.

I should add -- it would really help me to fix this bug, when time becomes available, if someone could figure out a way to reproduce in Firefox (the Midas demo or similar). If anyone does, post steps to reproduce and mention the comment number in the whiteboard. If it seems to only occur in Thunderbird, it will be hard for me to do anything to help, and maybe it should be refiled as a Thunderbird bug. (It might be an editor bug that's only easily triggered in Thunderbird, though.)

(In reply to :Aryeh Gregor from comment #39) Thanks Gregor for quick feedback. > I should add -- it would really help me to fix this bug, when time becomes > available, if someone could figure out a way to reproduce in Firefox (the > Midas demo or similar). If anyone does, post steps to reproduce and mention > the comment number in the whiteboard. Most welcome, here are the steps for FF (same as steps of comment 33, only that you do them in Midas Demo instead of composition window) 1 open http://www-archive.mozilla.org/editor/midasdemo/ 2 type "testung " (with final space) 3 check [x] view html source 4 add html code, resulting code like this: <font size="2">testung <br></font> 5 hit backspace 4 times to erase "ung " 6 type "ing x" to make it "I am testing x" where x is any alphanumeric character 7 observe spell check marks on "testing" (red squiggly) - I don't see this in Midas 8 verify HTML source (check [x] view html source), and find redundant font tags! > It might be an editor bug that's > only easily triggered in Thunderbird, though. An editor bug indeed, also present in FF, only more easily noticed in TB. I wonder how this affects applications that rely on the midas editor component, it must spoil their text input html code, too, which will be major data-disturbance when it happens.

(In reply to Seb from comment #37) > This bug can have serious implications when pasting in parts of link URLs -> added dataloss keyword

(In reply to Thomas D. from comment #40) > Most welcome, here are the steps for FF (same as steps of comment 33, only > that you do them in Midas Demo instead of composition window) > > 1 open http://www-archive.mozilla.org/editor/midasdemo/ > 2 type "testung " (with final space) > 3 check [x] view html source > 4 add html code, resulting code like this: > > <font size="2">testung <br></font> 4b uncheck [ ] view html source > 5 hit backspace 4 times to erase "ung " > 6 type "ing x" to make it "I am testing x" where x is any alphanumeric > character > 7 observe spell check marks on "testing" (red squiggly) - I don't see this > in Midas > 8 verify HTML source (check [x] view html source), and find redundant font > tags! > > > It might be an editor bug that's > > only easily triggered in Thunderbird, though. > > An editor bug indeed, also present in FF, only more easily noticed in TB. > I wonder how this affects applications that rely on the midas editor > component, it must spoil their text input html code, too, which will be > major data-disturbance when it happens.

Regarding FF vs. TB editor 1) I've also been experiencing the same random font-tag changes after backspacing, or midstream while typing within the TB editor (this obviously doesn't happen if the editor is set to "text only" vs. HTML emails) 2) Interestingly, as ThomasD pointed out, I just ran into the exact same problem when writing an email in AOL via FF... same random changes of font-size tags within the browser window composer. Likewise, in Ver 15 of TB, it worked perfectly... definitely noticed this in Ver 17 of TB (after an auto-update)

(In reply to micicarus from comment #45) > Regarding FF vs. TB editor > 1) I've also been experiencing the same random font-tag changes after > backspacing, or midstream while typing within the TB editor (this obviously > doesn't happen if the editor is set to "text only" vs. HTML emails) No, but I found that in trying to using text-only mode as a workaround, it apparently suffers from yet a different bug in which it removes spaces between words. It's as if https://bugzilla.mozilla.org/show_bug.cgi?id=823523 "Superfluous font tags in HTML mail cause spaces to disappear" somehow also reaches out to touch plain-text mode.

(In reply to micicarus from comment #45) > Regarding FF vs. TB editor > > 2) Interestingly, as ThomasD pointed out, I just ran into the exact same > problem when writing an email in AOL via FF... same random changes of > font-size tags within the browser window composer. I can also confirm that this is happening in FF, specifically when composing an email on the yahoo mail site (text gets bigger and bigger). Fixes: reset the zoom and leave it there, or, turn off 'zoom text only.' (Ultimately, having read here that leaving things at default prevents it, I just changed the default font to something bigger and left the zoom alone.)

The Thunderbird text editor is technically what we'd call an "abomination". Today I am motivated to write because it inserted font size changes at points where edits were made but no such font change specified. Reading the other complaints about similar issues, I beg you to start over with this editor, and abandon arguments that it's some irreplaceable legacy in an arcane language. Fire any manager that insists that, I respectfully advise. To the author: Compare the imperfect but evolved editor within Outlook Express and be duly ashamed. Having the ability to enter an HTML mode at least allows correction of the bugs manually - disappointing but at least salvageable. Issuing an editor some of whose bugs aren't even visible until after it's mailed, approaches punishable criminality. Thunderbird editor has made me look bad and I despise you for it. I like most everything else about the program. This can't be debugged, but it can be recreated by a clear headed programmer who documents all his/her code, is sane, and has the integrity to make an admirable program.

What I don't understand is why this changed. This worked fine until I upgraded to version 17.2 (I was on version 14 - wish I had stayed....) It make spell checker virtually useless. It occurs when I realize I have misspelled a word, and before I finish the word, I backspace to correct. Unless I erase the entire word, I get partial words underlined. (I have a portion of a screen shot, but this interface is apparently not set up to accept anything remotely graphical in nature.)

(In reply to Deb from comment #50) > <snip> > > (I have a portion of a screen shot, but this interface is apparently not set > up to accept anything remotely graphical in nature.) The place to add an Attachment is located near the top of the page, just below the bug's vital statistics and just above where the comments begin. There's a hyperlink there, under "Attachments" called "Add an attachment". It looks like you can add GIF, JPEG, and PNG graphical formats. I suspect that's what you're looking for...

When the email was sent, and then saved in my "Sent" folder, the font changed a bit randomly. Between Times (my preference) and Helvetica (the default?) Not good.

dataloss -> critical As shown in comment 42 (Midas STR), this is a bug in Core/Editor (not a TB bug). For FF and TB users affected by this bug, editor corrupts the source code very badly with unlimited <font...> tags bloat depending on how many corrections done. As a side effect, this renders the spell checker useless. Per comment #37, it also breaks links entered as text-only, then received and auto-linkified by TB (which fails because auto-linkification truncates the href attribute where the plaintext link has garbage <font...> tags, which might need a new bug for a more tolerant TB auto-linkification behaviour). (In reply to :Ehsan Akhgari from comment #15, 2012-11-22) > Aryeh, can you please give this a shot? (In reply to :Aryeh Gregor from comment #38, 2013-01-09) > I don't have time to work on anything at the moment. It will be at or close > to the top of my list for when I do, though. (In reply to :Aryeh Gregor from comment #39, 2013-01-09) > I should add -- it would really help me to fix this bug, when time becomes > available, if someone could figure out a way to reproduce in Firefox (the > Midas demo or similar). Aryeh, I have provided reduced STR for Midas demo in comment 42, as you requested. Is there anything else we can do to ease your start here and lure you into fixing this annoyance? ;)

(In reply to wwwizard from comment #49) > The Thunderbird text editor is technically what we'd call an "abomination". > Today I am motivated to write because it inserted font size changes at > points where edits were made but no such font change specified. Reading the > other complaints about similar issues, I beg you to start over with this > editor, and abandon arguments that it's some irreplaceable legacy in an > arcane language. We need it to be fixed quicker than can be done by a re-write. It should be determined what caused this current major breakage and that change should be reverted or fixed. It has worked well before and it cannot be held up that it was possible to change it and not possible to fix the breakage that results from that change. When it is unmaintainable, it should not be allowed that anyone touches it. Making changes, breaking it, and then running aways is simply not acceptable.

(In reply to :Aryeh Gregor from comment #39) > I should add -- it would really help me to fix this bug, when time becomes > available, if someone could figure out a way to reproduce in Firefox (the > Midas demo or similar). If anyone does, post steps to reproduce and mention > the comment number in the whiteboard. If it seems to only occur in > Thunderbird, it will be hard for me to do anything to help, and maybe it > should be refiled as a Thunderbird bug. (It might be an editor bug that's > only easily triggered in Thunderbird, though.) I can confirm that this bug is incredibly similar to (if not identical to) exactly the same behaviour (backspace inserts font size bloat tags) in the text / WYSIWYG editor for Moodle. It is so serious that it has caused the entire suspension of the development of Europe's largest online learning resource for film production training. All our content checking and correction volunteers (all unpaid) have had to stop work. Aryeh, Jet, we *desperately* need this issue fixing as - it seems - the issue is sufficiently deep in the core as to affect TB AND Firefox. I am sure almost every (editing) user of Moodle across the globe that loves and uses Firefox is experiencing the same problem. Your continued efforts and dedication to this awful problem are hugely appreciated. Let me know if I can help with end user debugging.

I see this bug too. I'm currently in Tucson, AZ for a CSS WG face-to-face meeting but I'll investigate this bug as soon as possible, tonight if I have spare cycles. I have a rather clear idea where this bug comes from and it seems to me yet another regression resulting from the "nested elements" rule changes and subsequent TypeInState fixes.

This bug seems to me a regression introduced by bug 590640 in patch part 7, very similar to the one handled in regression bug 757371.

Ok, found the guilty one and I was wrong, it's not bug 590640. http://hg.mozilla.org/mozilla-central/diff/ddd5acd40b93/editor/libeditor/html/nsHTMLEditorStyle.cpp So basically the "else" in the added code above is totally wrong because even if a property has a CSS equivalent, the corresponding style can be set by an HTML element or attribute... So the current bug is a regression introduced by the fix for bug 757371. Ehsan, Aryeh, Jet: the fix is trivial, just remove the "else". Please do, I still have a CSS WG ftf to co-chair...

Comment on attachment 710048 [details] [diff] [review] Patch (v1) Review of attachment 710048 [details] [diff] [review]: ----------------------------------------------------------------- I'm afraid I don't understand why this is wrong or how this code that's being removed could lead to extra tags being inserted.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #60) > I'm afraid I don't understand why this is wrong or how this code that's > being removed could lead to extra tags being inserted. Without looking closely, but based on Daniel's comment plus a rough understanding of what the code is supposed to do -- I think Daniel meant remove the word "else", so that it's two if's instead of if ... else if. The approximate meaning of the code as it stands is if (this property can be controlled by CSS) { if (this property is already set using CSS) { return NS_OK; } } else if (this property is already set using non-CSS) { return NS_OK; } The problem would be that if the property can be controlled by CSS (IsCSSEditableProperty) -- which is practically all properties -- we'll never check whether it's set using non-CSS means, e.g., <font>. Thus it gets re-set, even though it's already set, which means useless extra tags are added ad infinitum. Removing the "else" will make the non-CSS check happen in all cases, which offhand seems like what we want. So if I understand correctly, Ehsan's patch is not what Daniel meant -- but I didn't try testing anything on an actual build. At a glance, I don't think it's a regression from bug 757371, I think the fix there is just incomplete. I'd think it's a regression from bug 590640, which bug 757371 fixed incompletely.

Thinking a bit more -- removing the "else" probably isn't right either, and would cause different regressions. IsCSSEquivalentToHTMLInlineStyleSet is being used to check computed styles here, which is correct for everything except font size, due to (basically) bug 747889. Removing the "else" entirely would mean that for all other properties you'd be checking twice, and the second check would be incorrect because it would ignore CSS. E.g., <font color=green><span style=color:blue> would return "green" from IsTextPropertySetByContent. So the root cause of this bug was, I suspect, bug 480647 part 6. Prior to that, IsCSSEditableProperty would return false for font size and we'd go down the correct path here. Now we don't, except CSS for font size is only half-implemented, so neither code path really works. Ultimately I think backing that patch out (and changing the spec to match) is best. For a workaround here that's less likely to cause yet more regressions, I'd do an extra IsTextPropertySetByContent check for font size in addition to the non-IsCSSEditableProperty case, even though that will still be wrong in some cases because of the current state of font size.

Comment on attachment 710048 [details] [diff] [review] Patch (v1) r- ; this patch is wrong :-) I said « removing the "else" », not the else case. So it's really about removing the four characters "else" (and inserting a CR if you want)...

(In reply to :Aryeh Gregor from comment #62) > Thinking a bit more -- removing the "else" probably isn't right either, and > would cause different regressions. IsCSSEquivalentToHTMLInlineStyleSet is > being used to check computed styles here, which is correct for everything > except font size, due to (basically) bug 747889. Removing the "else" > entirely would mean that for all other properties you'd be checking twice, > and the second check would be incorrect because it would ignore CSS. E.g., > <font color=green><span style=color:blue> would return "green" from > IsTextPropertySetByContent. > > So the root cause of this bug was, I suspect, bug 480647 part 6. Prior to > that, IsCSSEditableProperty would return false for font size and we'd go > down the correct path here. Now we don't, except CSS for font size is only > half-implemented, so neither code path really works. Ultimately I think > backing that patch out (and changing the spec to match) is best. For a > workaround here that's less likely to cause yet more regressions, I'd do an > extra IsTextPropertySetByContent check for font size in addition to the > non-IsCSSEditableProperty case, even though that will still be wrong in some > cases because of the current state of font size. Yeah, that's unfortunately possible, I don't know the full extent of the changes you did and your patches are sometimes extremely difficult to read because of the heavy cleanup you often do at same time. If you back out your patch, make sure to back out too all the regressions fixes if any.

(In reply to comment #63) > Comment on attachment 710048 [details] [diff] [review] > --> https://bugzilla.mozilla.org/attachment.cgi?id=710048 > Patch (v1) > > r- ; this patch is wrong :-) I said « removing the "else" », not the else case. > So it's really about removing the four characters "else" (and inserting > a CR if you want)... Can you please let us know how you tested this change? I'd really like us to at least add a test case for this. The fact that all of our tests pass with this patch is scary...

(In reply to :Ehsan Akhgari (Away 2/7-2/15) from comment #65) > Can you please let us know how you tested this change? I'd really like us > to at least add a test case for this. The fact that all of our tests pass > with this patch is scary... I did not have time to write a test, Ehsan... I am right in the middle of a CSS WG meeting I'm co-chairing! So I made the change in my mozilla-central clone, rebuilt and used the Midas demo to reproduce the steps outlined above in the bug. I do agree with Aryeh that there could be side-effects unknown to me because he implemented quite heavy changes to the editor in the last months. At least, my investigation led to a better understanding of what's going on : the bug occurs because the spotted code sees the font-size property is "CSSable" and not currently applied to the markup through CSS; it's then not looking at the markup context. I hope it's going to help you guys narrowing the issue and fixing it ASAP given the incredibly high impact on inline wysiwyg editors seen by users. Sorry but given my role and time schedule here in the CSS WG ftf, I can't do more.

(In reply to :Aryeh Gregor from comment #62) > Thinking a bit more -- removing the "else" probably isn't right either, and > would cause different regressions. IsCSSEquivalentToHTMLInlineStyleSet is > being used to check computed styles here, which is correct for everything > except font size, due to (basically) bug 747889. Removing the "else" > entirely would mean that for all other properties you'd be checking twice, > and the second check would be incorrect because it would ignore CSS. E.g., > <font color=green><span style=color:blue> would return "green" from > IsTextPropertySetByContent. > > So the root cause of this bug was, I suspect, bug 480647 part 6. Prior to > that, IsCSSEditableProperty would return false for font size and we'd go > down the correct path here. Now we don't, except CSS for font size is only > half-implemented, so neither code path really works. Ultimately I think > backing that patch out (and changing the spec to match) is best. For a > workaround here that's less likely to cause yet more regressions, I'd do an > extra IsTextPropertySetByContent check for font size in addition to the > non-IsCSSEditableProperty case, even though that will still be wrong in some > cases because of the current state of font size. I tried backing out bug 480647 part 6 but unfortunately a lot has landed on top of it and it seems very difficult to revert correctly. I'm afraid I won't have time to look into this before I go to vacation. Aryeh, any chance you could try backing out that patch? If not, Jet, I'd appreciate if you can find an owner for this. Thanks!

OK, I'll pick this up. Based on your last comment, cleanly backing out bug 480647 part 6 is the recommended course. Please reply if I've misread that, or if there are other to-do items here.

WIP patch backs out bug 480647 (part 6) but has these test failures: C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-dM C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-body C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-div CC-Proposed-FS:1_SPANs:fs:l-1_SW-dM CC-Proposed-FS:1_SPANs:fs:l-1_SW-body CC-Proposed-FS:1_SPANs:fs:l-1_SW-div CC-Proposed-FS:4_SPANs:fs:l-1_SW-dM CC-Proposed-FS:4_SPANs:fs:l-1_SW-body CC-Proposed-FS:4_SPANs:fs:l-1_SW-div CC-Proposed-FS:4_SPANs:fs:18px-1_SW-dM CC-Proposed-FS:4_SPANs:fs:18px-1_SW-body CC-Proposed-FS:4_SPANs:fs:18px-1_SW-div These tests were removed from the known failures list in bug 480647 (part 6.) Need feedback on why these fail with "got 0, expected 1"

Updated patch resolves "select" test failures found earlier.

Comment on attachment 710532 [details] [diff] [review] Patch backs out bug 480647 part 6 ># HG changeset patch ># User Jet Villegas <jet@mozilla.com> ># Date 1360130459 28800 ># Node ID 45d9027d353d499d9ded4c3e8a23e7c78140ac50 ># Parent 7f82f74de11f43c1b7b11187b82339f92263dd69 >Bug 812638: revert fix for bug 480647 (part 6) that introduced this regression. > >diff --git a/editor/libeditor/html/nsHTMLCSSUtils.cpp b/editor/libeditor/html/nsHTMLCSSUtils.cpp >--- a/editor/libeditor/html/nsHTMLCSSUtils.cpp >+++ b/editor/libeditor/html/nsHTMLCSSUtils.cpp >@@ -178,55 +178,16 @@ void ProcessMarginRightValue(const nsASt > aOutputString.AppendLiteral("auto"); > } > else { > aOutputString.AppendLiteral("0px"); > } > } > } > >-static >-void ProcessFontSizeValue(const nsAString* aInputString, nsAString& aOutputString, >- const char* aDefaultValueString, >- const char* aPrependString, const char* aAppendString) >-{ >- aOutputString.Truncate(); >- if (aInputString) { >- int32_t size = nsContentUtils::ParseLegacyFontSize(*aInputString); >- switch (size) { >- case 0: >- // Didn't parse >- return; >- case 1: >- aOutputString.AssignLiteral("x-small"); >- return; >- case 2: >- aOutputString.AssignLiteral("small"); >- return; >- case 3: >- aOutputString.AssignLiteral("medium"); >- return; >- case 4: >- aOutputString.AssignLiteral("large"); >- return; >- case 5: >- aOutputString.AssignLiteral("x-large"); >- return; >- case 6: >- aOutputString.AssignLiteral("xx-large"); >- return; >- case 7: >- // No corresponding CSS size >- return; >- default: >- NS_NOTREACHED("Unexpected return value from ParseLegacyFontSize"); >- } >- } >-} >- > const nsHTMLCSSUtils::CSSEquivTable boldEquivTable[] = { > { nsHTMLCSSUtils::eCSSEditableProperty_font_weight, ProcessBValue, nullptr, nullptr, nullptr, true, false }, > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } > }; > > const nsHTMLCSSUtils::CSSEquivTable italicEquivTable[] = { > { nsHTMLCSSUtils::eCSSEditableProperty_font_style, ProcessDefaultValue, "italic", nullptr, nullptr, true, false }, > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } >@@ -252,21 +213,16 @@ const nsHTMLCSSUtils::CSSEquivTable font > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } > }; > > const nsHTMLCSSUtils::CSSEquivTable fontFaceEquivTable[] = { > { nsHTMLCSSUtils::eCSSEditableProperty_font_family, ProcessSameValue, nullptr, nullptr, nullptr, true, false }, > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } > }; > >-const nsHTMLCSSUtils::CSSEquivTable fontSizeEquivTable[] = { >- { nsHTMLCSSUtils::eCSSEditableProperty_font_size, ProcessFontSizeValue, nullptr, nullptr, nullptr, true, false }, >- { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } >-}; >- > const nsHTMLCSSUtils::CSSEquivTable bgcolorEquivTable[] = { > { nsHTMLCSSUtils::eCSSEditableProperty_background_color, ProcessSameValue, nullptr, nullptr, nullptr, true, false }, > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } > }; > > const nsHTMLCSSUtils::CSSEquivTable backgroundImageEquivTable[] = { > { nsHTMLCSSUtils::eCSSEditableProperty_background_image, ProcessExtendedValue, nullptr, "url(", ")", true, true }, > { nsHTMLCSSUtils::eCSSEditableProperty_NONE, 0 } >@@ -342,31 +298,29 @@ nsHTMLCSSUtils::~nsHTMLCSSUtils() > { > } > > // Answers true if we have some CSS equivalence for the HTML style defined > // by aProperty and/or aAttribute for the node aNode > bool > nsHTMLCSSUtils::IsCSSEditableProperty(nsIDOMNode* aNode, > nsIAtom* aProperty, >- const nsAString* aAttribute, >- const nsAString* aValue) >+ const nsAString* aAttribute) > { > NS_ASSERTION(aNode, "Shouldn't you pass aNode? - Bug 214025"); > > nsCOMPtr<nsIContent> content = do_QueryInterface(aNode); > NS_ENSURE_TRUE(content, false); >- return IsCSSEditableProperty(content, aProperty, aAttribute, aValue); >+ return IsCSSEditableProperty(content, aProperty, aAttribute); > } > > bool > nsHTMLCSSUtils::IsCSSEditableProperty(nsIContent* aNode, > nsIAtom* aProperty, >- const nsAString* aAttribute, >- const nsAString* aValue) >+ const nsAString* aAttribute) > { > MOZ_ASSERT(aNode); > > nsIContent* content = aNode; > // we need an element node here > if (content->NodeType() == nsIDOMNode::TEXT_NODE) { > content = content->GetParent(); > NS_ENSURE_TRUE(content, false); >@@ -382,26 +336,16 @@ nsHTMLCSSUtils::IsCSSEditableProperty(ns > || nsEditProperty::u == aProperty > || nsEditProperty::strike == aProperty > || ((nsEditProperty::font == aProperty) && aAttribute && > (aAttribute->EqualsLiteral("color") || > aAttribute->EqualsLiteral("face")))) { > return true; > } > >- // FONT SIZE doesn't work if the value is 7 >- if (nsEditProperty::font == aProperty && aAttribute && >- aAttribute->EqualsLiteral("size")) { >- if (!aValue || aValue->IsEmpty()) { >- return true; >- } >- int32_t size = nsContentUtils::ParseLegacyFontSize(*aValue); >- return size && size != 7; >- } >- > // ALIGN attribute on elements supporting it > if (aAttribute && (aAttribute->EqualsLiteral("align")) && > (nsEditProperty::div == tagName > || nsEditProperty::p == tagName > || nsEditProperty::h1 == tagName > || nsEditProperty::h2 == tagName > || nsEditProperty::h3 == tagName > || nsEditProperty::h4 == tagName >@@ -903,19 +847,16 @@ nsHTMLCSSUtils::GenerateCSSDeclarationsF > equivTable = ttEquivTable; > } else if (aAttribute) { > if (nsEditProperty::font == aHTMLProperty && > aAttribute->EqualsLiteral("color")) { > equivTable = fontColorEquivTable; > } else if (nsEditProperty::font == aHTMLProperty && > aAttribute->EqualsLiteral("face")) { > equivTable = fontFaceEquivTable; >- } else if (nsEditProperty::font == aHTMLProperty && >- aAttribute->EqualsLiteral("size")) { >- equivTable = fontSizeEquivTable; > } else if (aAttribute->EqualsLiteral("bgcolor")) { > equivTable = bgcolorEquivTable; > } else if (aAttribute->EqualsLiteral("background")) { > equivTable = backgroundImageEquivTable; > } else if (aAttribute->EqualsLiteral("text")) { > equivTable = textColorEquivTable; > } else if (aAttribute->EqualsLiteral("border")) { > equivTable = borderEquivTable; >@@ -984,18 +925,17 @@ nsHTMLCSSUtils::SetCSSEquivalentToHTMLSt > nsIAtom *aHTMLProperty, > const nsAString *aAttribute, > const nsAString *aValue, > int32_t * aCount, > bool aSuppressTransaction) > { > nsCOMPtr<dom::Element> element = do_QueryInterface(aNode); > *aCount = 0; >- if (!element || !IsCSSEditableProperty(element, aHTMLProperty, >- aAttribute, aValue)) { >+ if (!element || !IsCSSEditableProperty(element, aHTMLProperty, aAttribute)) { > return NS_OK; > } > > // we can apply the styles only if the node is an element and if we have > // an equivalence for the requested HTML style in this implementation > > // Find the CSS equivalence to the HTML style > nsTArray<nsIAtom*> cssPropertyArray; >@@ -1061,18 +1001,17 @@ nsHTMLCSSUtils::GetCSSEquivalentToHTMLIn > const nsAString *aAttribute, > nsAString & aValueString, > StyleType aStyleType) > { > aValueString.Truncate(); > nsCOMPtr<dom::Element> theElement = GetElementContainerOrSelf(aNode); > NS_ENSURE_TRUE(theElement, NS_ERROR_NULL_POINTER); > >- if (!theElement || !IsCSSEditableProperty(theElement, aHTMLProperty, >- aAttribute, &aValueString)) { >+ if (!theElement || !IsCSSEditableProperty(theElement, aHTMLProperty, aAttribute)) { > return NS_OK; > } > > // Yes, the requested HTML style has a CSS equivalence in this implementation > nsTArray<nsIAtom*> cssPropertyArray; > nsTArray<nsString> cssValueArray; > // get the CSS equivalence with last param true indicating we want only the > // "gettable" properties >@@ -1239,29 +1178,16 @@ nsHTMLCSSUtils::IsCSSEquivalentToHTMLInl > } else { > // ignore this, it's TT or our default > nsAutoString valueStringLower; > ToLowerCase(valueString, valueStringLower); > aIsSet = !valueStringLower.EqualsLiteral("monospace") && > !valueStringLower.EqualsLiteral("serif"); > } > return NS_OK; >- } else if (nsEditProperty::font == aHTMLProperty && aHTMLAttribute && >- aHTMLAttribute->EqualsLiteral("size")) { >- if (htmlValueString.IsEmpty()) { >- aIsSet = true; >- } else { >- int32_t size = nsContentUtils::ParseLegacyFontSize(htmlValueString); >- aIsSet = (size == 1 && valueString.EqualsLiteral("x-small")) || >- (size == 2 && valueString.EqualsLiteral("small")) || >- (size == 3 && valueString.EqualsLiteral("medium")) || >- (size == 4 && valueString.EqualsLiteral("large")) || >- (size == 5 && valueString.EqualsLiteral("x-large")) || >- (size == 6 && valueString.EqualsLiteral("xx-large")); >- } > } else if (aHTMLAttribute && aHTMLAttribute->EqualsLiteral("align")) { > aIsSet = true; > } else { > aIsSet = false; > return NS_OK; > } > > if (!htmlValueString.IsEmpty() && >diff --git a/editor/libeditor/html/nsHTMLCSSUtils.h b/editor/libeditor/html/nsHTMLCSSUtils.h >--- a/editor/libeditor/html/nsHTMLCSSUtils.h >+++ b/editor/libeditor/html/nsHTMLCSSUtils.h >@@ -77,28 +77,19 @@ public: > /** answers true if the given combination element_name/attribute_name > * has a CSS equivalence in this implementation > * > * @return a boolean saying if the tag/attribute has a css equiv > * @param aNode [IN] a DOM node > * @param aProperty [IN] an atom containing a HTML tag name > * @param aAttribute [IN] a string containing the name of a HTML > * attribute carried by the element above >- * @param aValue [IN] an optional string containing the attribute's >- * HTML value -- this matters for <font size>, >- * since size=7 has no CSS equivalent. Make sure >- * you pass the HTML value (e.g. "4"), not the >- * CSS value (e.g. "large"). > */ >- bool IsCSSEditableProperty(nsIContent* aNode, nsIAtom* aProperty, >- const nsAString* aAttribute, >- const nsAString* aValue = nullptr); >- bool IsCSSEditableProperty(nsIDOMNode* aNode, nsIAtom* aProperty, >- const nsAString* aAttribute, >- const nsAString* aValue = nullptr); >+ bool IsCSSEditableProperty(nsIContent* aNode, nsIAtom* aProperty, const nsAString* aAttribute); >+ bool IsCSSEditableProperty(nsIDOMNode* aNode, nsIAtom* aProperty, const nsAString* aAttribute); > > /** adds/remove a CSS declaration to the STYLE atrribute carried by a given element > * > * @param aElement [IN] a DOM element > * @param aProperty [IN] an atom containing the CSS property to set > * @param aValue [IN] a string containing the value of the CSS property > * @param aSuppressTransaction [IN] a boolean indicating, when true, > * that no transaction should be recorded >diff --git a/editor/libeditor/html/nsHTMLEditorStyle.cpp b/editor/libeditor/html/nsHTMLEditorStyle.cpp >--- a/editor/libeditor/html/nsHTMLEditorStyle.cpp >+++ b/editor/libeditor/html/nsHTMLEditorStyle.cpp >@@ -307,18 +307,17 @@ nsHTMLEditor::IsSimpleModifiableNode(nsI > // Property-specific handling is needed (bug 760211). > return true; > } > } > > // No luck so far. Now we check for a <span> with a single style="" > // attribute that sets only the style we're looking for, if this type of > // style supports it >- if (!mHTMLCSSUtils->IsCSSEditableProperty(element, aProperty, >- aAttribute, aValue) || >+ if (!mHTMLCSSUtils->IsCSSEditableProperty(element, aProperty, aAttribute) || > !element->IsHTML(nsGkAtoms::span) || element->GetAttrCount() != 1 || > !element->HasAttr(kNameSpaceID_None, nsGkAtoms::style)) { > return false; > } > > // Some CSS styles are not so simple. For instance, underline is > // "text-decoration: underline", which decomposes into four different text-* > // properties. So for now, we just create a span, add the desired style, and >@@ -356,18 +355,17 @@ nsHTMLEditor::SetInlinePropertyOnTextNod > > // don't need to do anything if no characters actually selected > if (aStartOffset == aEndOffset) return NS_OK; > > nsCOMPtr<nsIDOMNode> node = aTextNode; > > // don't need to do anything if property already set on node > bool bHasProp; >- if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, >- aAttribute, aValue)) { >+ if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, aAttribute)) { > // the HTML styles defined by aProperty/aAttribute has a CSS equivalence > // in this implementation for node; let's check if it carries those css styles > nsAutoString value(*aValue); > mHTMLCSSUtils->IsCSSEquivalentToHTMLInlineStyleSet(node, aProperty, aAttribute, > bHasProp, value, > nsHTMLCSSUtils::eComputed); > } else { > IsTextPropertySetByContent(node, aProperty, aAttribute, aValue, bHasProp); >@@ -466,30 +464,28 @@ nsHTMLEditor::SetInlinePropertyOnNodeImp > } > if (IsSimpleModifiableNode(nextSibling, aProperty, aAttribute, aValue)) { > res = MoveNode(aNode, nextSibling, 0); > NS_ENSURE_SUCCESS(res, res); > return NS_OK; > } > > // don't need to do anything if property already set on node >- if (mHTMLCSSUtils->IsCSSEditableProperty(aNode, aProperty, >- aAttribute, aValue)) { >+ if (mHTMLCSSUtils->IsCSSEditableProperty(aNode, aProperty, aAttribute)) { > if (mHTMLCSSUtils->IsCSSEquivalentToHTMLInlineStyleSet( > aNode, aProperty, aAttribute, *aValue, nsHTMLCSSUtils::eComputed)) { > return NS_OK; > } > } else if (IsTextPropertySetByContent(aNode, aProperty, > aAttribute, aValue)) { > return NS_OK; > } > > bool useCSS = (IsCSSEnabled() && >- mHTMLCSSUtils->IsCSSEditableProperty(aNode, aProperty, >- aAttribute, aValue)) || >+ mHTMLCSSUtils->IsCSSEditableProperty(aNode, aProperty, aAttribute)) || > // bgcolor is always done using CSS > aAttribute->EqualsLiteral("bgcolor"); > > if (useCSS) { > nsCOMPtr<dom::Element> tmp; > // We only add style="" to <span>s with no attributes (bug 746515). If we > // don't have one, we need to make one. > if (aNode->IsElement() && aNode->AsElement()->IsHTML(nsGkAtoms::span) && >@@ -1152,21 +1148,17 @@ nsHTMLEditor::GetInlinePropertyBase(nsIA > } else { > mTypeInState->GetTypingState(isSet, theSetting, aProperty); > } > if (isSet) { > *aFirst = *aAny = *aAll = theSetting; > return NS_OK; > } > >- // Bug 747889: we don't support CSS for fontSize values >- if ((aProperty != nsEditProperty::font || >- !aAttribute->EqualsLiteral("size")) && >- mHTMLCSSUtils->IsCSSEditableProperty(collapsedNode, aProperty, >- aAttribute)) { >+ if (mHTMLCSSUtils->IsCSSEditableProperty(collapsedNode, aProperty, aAttribute)) { > mHTMLCSSUtils->IsCSSEquivalentToHTMLInlineStyleSet( > collapsedNode, aProperty, aAttribute, isSet, tOutString, > nsHTMLCSSUtils::eComputed); > if (outValue) { > outValue->Assign(tOutString); > } > *aFirst = *aAny = *aAll = isSet; > return NS_OK; >@@ -1240,21 +1232,17 @@ nsHTMLEditor::GetInlinePropertyBase(nsIA > } > } else if (content->IsElement()) { > // handle non-text leaf nodes here > continue; > } > > bool isSet = false; > if (first) { >- if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, >- aAttribute) && >- // Bug 747889: we don't support CSS for fontSize values >- (aProperty != nsEditProperty::font || >- !aAttribute->EqualsLiteral("size"))) { >+ if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, aAttribute)){ > // the HTML styles defined by aProperty/aAttribute has a CSS > // equivalence in this implementation for node; let's check if it > // carries those css styles > if (aValue) { > firstValue.Assign(*aValue); > } > mHTMLCSSUtils->IsCSSEquivalentToHTMLInlineStyleSet(node, aProperty, > aAttribute, isSet, firstValue, nsHTMLCSSUtils::eComputed); >@@ -1263,21 +1251,17 @@ nsHTMLEditor::GetInlinePropertyBase(nsIA > &firstValue); > } > *aFirst = isSet; > first = false; > if (outValue) { > *outValue = firstValue; > } > } else { >- if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, >- aAttribute) && >- // Bug 747889: we don't support CSS for fontSize values >- (aProperty != nsEditProperty::font || >- !aAttribute->EqualsLiteral("size"))) { >+ if (mHTMLCSSUtils->IsCSSEditableProperty(node, aProperty, aAttribute)){ > // the HTML styles defined by aProperty/aAttribute has a CSS equivalence > // in this implementation for node; let's check if it carries those css styles > if (aValue) { > theValue.Assign(*aValue); > } > mHTMLCSSUtils->IsCSSEquivalentToHTMLInlineStyleSet(node, aProperty, > aAttribute, isSet, theValue, nsHTMLCSSUtils::eComputed); > } else { >diff --git a/editor/libeditor/html/tests/browserscope/lib/richtext/currentStatus.js b/editor/libeditor/html/tests/browserscope/lib/richtext/currentStatus.js >--- a/editor/libeditor/html/tests/browserscope/lib/richtext/currentStatus.js >+++ b/editor/libeditor/html/tests/browserscope/lib/richtext/currentStatus.js >@@ -14,28 +14,33 @@ var knownFailures = { > 'change' : { > '0-undefined' : true > }, > 'query' : { > '0-undefined' : true > }, > 'a' : { > 'createbookmark-0' : true, >+ 'fontsize-1' : true, > 'subscript-1' : true, > 'superscript-1' : true, > }, > 'u': { > 'removeformat-1' : true, > 'removeformat-2' : true, > 'strikethrough-2' : true, > 'subscript-1' : true, > 'superscript-1' : true, > 'unbookmark-0' : true, > }, > 'q': { > 'fontsize-1' : true, > 'fontsize-2' : true, > }, >+ 'c': { >+ 'fontsize-1' : true, >+ 'fontsize-2' : true, >+ }, > }; > > function isKnownFailure(type, test, param) { > return (type in knownFailures) && ((test + "-" + param) in knownFailures[type]); > } >diff --git a/editor/libeditor/html/tests/browserscope/lib/richtext2/currentStatus.js b/editor/libeditor/html/tests/browserscope/lib/richtext2/currentStatus.js >--- a/editor/libeditor/html/tests/browserscope/lib/richtext2/currentStatus.js >+++ b/editor/libeditor/html/tests/browserscope/lib/richtext2/currentStatus.js >@@ -15,16 +15,19 @@ const knownFailures = { > "A-Proposed-CB:name_TEXT-1_SI-body": true, > "A-Proposed-CB:name_TEXT-1_SI-div": true, > "AC-Proposed-SUB_TEXT-1_SI-dM": true, > "AC-Proposed-SUB_TEXT-1_SI-body": true, > "AC-Proposed-SUB_TEXT-1_SI-div": true, > "AC-Proposed-SUP_TEXT-1_SI-dM": true, > "AC-Proposed-SUP_TEXT-1_SI-body": true, > "AC-Proposed-SUP_TEXT-1_SI-div": true, >+ "AC-Proposed-FS:2_TEXT-1_SI-dM": true, >+ "AC-Proposed-FS:2_TEXT-1_SI-body": true, >+ "AC-Proposed-FS:2_TEXT-1_SI-div": true, > "AC-Proposed-FS:18px_TEXT-1_SI-dM": true, > "AC-Proposed-FS:18px_TEXT-1_SI-body": true, > "AC-Proposed-FS:18px_TEXT-1_SI-div": true, > "AC-Proposed-FS:large_TEXT-1_SI-dM": true, > "AC-Proposed-FS:large_TEXT-1_SI-body": true, > "AC-Proposed-FS:large_TEXT-1_SI-div": true, > "C-Proposed-BC:ace_FONT.ass.s:bc:rgb-1_SW-dM": true, > "C-Proposed-BC:ace_FONT.ass.s:bc:rgb-1_SW-body": true, >@@ -36,16 +39,19 @@ const knownFailures = { > "C-Proposed-FN:c_FONTf:a-1_SI-body": true, > "C-Proposed-FN:c_FONTf:a-1_SI-div": true, > "C-Proposed-FN:c_FONTf:a-2_SL-dM": true, > "C-Proposed-FN:c_FONTf:a-2_SL-body": true, > "C-Proposed-FN:c_FONTf:a-2_SL-div": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-dM": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-body": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-div": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-dM": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-body": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-div": true, > "C-Proposed-FS:larger_FONTsz:4-dM": true, > "C-Proposed-FS:larger_FONTsz:4-body": true, > "C-Proposed-FS:larger_FONTsz:4-div": true, > "C-Proposed-FS:smaller_FONTsz:4-dM": true, > "C-Proposed-FS:smaller_FONTsz:4-body": true, > "C-Proposed-FS:smaller_FONTsz:4-div": true, > "C-Proposed-FB:h1_ADDRESS-FONTsz:4-1_SO-dM": true, > "C-Proposed-FB:h1_ADDRESS-FONTsz:4-1_SO-body": true, >@@ -72,19 +78,28 @@ const knownFailures = { > "CC-Proposed-BC:gray_SPANs:bc:b-2_SR-body": true, > "CC-Proposed-BC:gray_SPANs:bc:b-2_SR-div": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-dM": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-body": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-div": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-dM": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-body": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-div": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-dM": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-body": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-div": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-dM": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-body": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-div": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-dM": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-body": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-div": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-dM": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-body": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-div": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-dM": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-body": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-div": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-dM": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-body": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-div": true, > "U-RFC-UNLINK_A-1_SO-dM": true, > "U-RFC-UNLINK_A-1_SO-body": true, >@@ -658,16 +673,19 @@ const knownFailures = { > "C-Proposed-FN:c_FONTf:a-1_SI-body": true, > "C-Proposed-FN:c_FONTf:a-1_SI-div": true, > "C-Proposed-FN:c_FONTf:a-2_SL-dM": true, > "C-Proposed-FN:c_FONTf:a-2_SL-body": true, > "C-Proposed-FN:c_FONTf:a-2_SL-div": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-dM": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-body": true, > "C-Proposed-FS:1_SPAN.ass.s:fs:large-1_SW-div": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-dM": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-body": true, >+ "C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-div": true, > "C-Proposed-FS:2_FONTc:b.sz:6-1_SI-dM": true, > "C-Proposed-FS:2_FONTc:b.sz:6-1_SI-body": true, > "C-Proposed-FS:2_FONTc:b.sz:6-1_SI-div": true, > "C-Proposed-FS:larger_FONTsz:4-dM": true, > "C-Proposed-FS:larger_FONTsz:4-body": true, > "C-Proposed-FS:larger_FONTsz:4-div": true, > "C-Proposed-FS:smaller_FONTsz:4-dM": true, > "C-Proposed-FS:smaller_FONTsz:4-body": true, >@@ -703,19 +721,28 @@ const knownFailures = { > "CC-Proposed-BC:gray_SPANs:bc:b-2_SR-body": true, > "CC-Proposed-BC:gray_SPANs:bc:b-2_SR-div": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-dM": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-body": true, > "CC-Proposed-FN:c_FONTf:a-1_SI-div": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-dM": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-body": true, > "CC-Proposed-FN:c_FONTf:a-2_SL-div": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-dM": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-body": true, >+ "CC-Proposed-FS:1_SPANs:fs:l-1_SW-div": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-dM": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-body": true, > "CC-Proposed-FS:18px_SPANs:fs:l-1_SW-div": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-dM": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-body": true, >+ "CC-Proposed-FS:4_SPANs:fs:l-1_SW-div": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-dM": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-body": true, >+ "CC-Proposed-FS:4_SPANs:fs:18px-1_SW-div": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-dM": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-body": true, > "CC-Proposed-FS:larger_SPANs:fs:l-1_SI-div": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-dM": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-body": true, > "CC-Proposed-FS:smaller_SPANs:fs:l-1_SI-div": true, > "U-RFC-UNLINK_A-1_SO-dM": true, > "U-RFC-UNLINK_A-1_SO-body": true, >diff --git a/editor/libeditor/html/tests/test_bug480647.html b/editor/libeditor/html/tests/test_bug480647.html >--- a/editor/libeditor/html/tests/test_bug480647.html >+++ b/editor/libeditor/html/tests/test_bug480647.html >@@ -16,57 +16,26 @@ function parseFontSize(input, expected) > parseFontSizeInner(input, expected, is); > } > > function parseFontSizeTodo(input, expected) { > parseFontSizeInner(input, expected, todo_is); > } > > function parseFontSizeInner(input, expected, fn) { >- // First test non-CSS >- document.execCommand("styleWithCSS", false, false); > div.innerHTML = "foo"; > getSelection().selectAllChildren(div); > document.execCommand("fontSize", false, input); > if (expected === null) { > fn(div.innerHTML, "foo", >- 'execCommand("fontSize", false, "' + input + '") should be no-op ' + >- '(non-CSS)'); >+ 'execCommand("fontSize", false, "' + input + '") should be no-op'); > } else { > fn(div.innerHTML, '<font size="' + expected + '">foo</font>', > 'execCommand("fontSize", false, "' + input + '") should parse to ' + >- expected + ' (non-CSS)'); >- } >- >- // Now test CSS >- document.execCommand("styleWithCSS", false, true); >- div.innerHTML = "foo"; >- getSelection().selectAllChildren(div); >- document.execCommand("fontSize", false, input); >- if (expected === null) { >- fn(div.innerHTML, "foo", >- 'execCommand("fontSize", false, "' + input + '") should be no-op ' + >- '(CSS)'); >- } else if (expected === 7) { >- // No CSS support for <font size=7> >- fn(div.innerHTML, '<font size="' + expected + '">foo</font>', >- 'execCommand("fontSize", false, "' + input + '") should parse to ' + >- expected + ' (CSS)'); >- } else { >- var cssVal = { >- 1: "x-small", >- 2: "small", >- 3: "medium", >- 4: "large", >- 5: "x-large", >- 6: "xx-large", >- }[expected]; >- fn(div.innerHTML, '<span style="font-size: ' + cssVal + ';">foo</span>', >- 'execCommand("fontSize", false, "' + input + '") should parse to ' + >- expected + ' (CSS)'); >+ expected); > } > } > > // Parse errors > parseFontSize("", null); > parseFontSize("abc", null); > parseFontSize("larger", null); > parseFontSize("smaller", null);

(In reply to Jet Villegas (:jet) from comment #69) > Created attachment 710453 [details] [diff] [review] > WIP patch > > WIP patch backs out bug 480647 (part 6) but has these test failures: > > C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-dM > C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-body > C-Proposed-FS:5_FONTsz:1.s:fs:xs-1_SW-div > CC-Proposed-FS:1_SPANs:fs:l-1_SW-dM > CC-Proposed-FS:1_SPANs:fs:l-1_SW-body > CC-Proposed-FS:1_SPANs:fs:l-1_SW-div > CC-Proposed-FS:4_SPANs:fs:l-1_SW-dM > CC-Proposed-FS:4_SPANs:fs:l-1_SW-body > CC-Proposed-FS:4_SPANs:fs:l-1_SW-div > CC-Proposed-FS:4_SPANs:fs:18px-1_SW-dM > CC-Proposed-FS:4_SPANs:fs:18px-1_SW-body > CC-Proposed-FS:4_SPANs:fs:18px-1_SW-div > > These tests were removed from the known failures list in bug 480647 (part > 6.) Need feedback on why these fail with "got 0, expected 1" You probably need to regenerate the currentStatus.js file as described in http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/html/tests/browserscope/lib/richtext2/README.Mozilla?force=1#19.

Comment on attachment 710532 [details] [diff] [review] Patch backs out bug 480647 part 6 Review of attachment 710532 [details] [diff] [review]: ----------------------------------------------------------------- r=me if this fixes the regression as described in comment 40 (and with comment 72 addressed.)

I triggered a Thunderbird try build with this patch, builds should appear at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/mcsmurf@mcsmurf.de-5cd14a55cdde soon for testing. Test results should appear at https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=5cd14a55cdde

Backed out for mochitest failures. https://hg.mozilla.org/integration/mozilla-inbound/rev/b04245038b27 https://tbpl.mozilla.org/php/getParsedLog.php?id=19495590&tree=Mozilla-Inbound

(In reply to Frank Wein [:mcsmurf] from comment #74) > I triggered a Thunderbird try build with this patch, builds should appear at > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/ > mcsmurf@mcsmurf.de-5cd14a55cdde soon for testing. Test results should appear > at https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=5cd14a55cdde The patch resolves the Firefox STR. Did it work for Thunderbird?

(In reply to Jet Villegas (:jet) from comment #78) > The patch resolves the Firefox STR. Did it work for Thunderbird? Someone else will test as soon as the patch will land again, I created the try build for someone on IRC who wanted to test the patch before it landed. Somehow my try build did not work, not sure why (patch failed to apply).

https://hg.mozilla.org/integration/mozilla-inbound/rev/41a3c03feff3 https://hg.mozilla.org/integration/mozilla-inbound/rev/9c164a7f5f75

You guys are awesome! Based on "Target Milestone: mozilla21" we should see this around May 2013, right (https://wiki.mozilla.org/RapidRelease/Calendar)? Or could we patch it in earlier?

(In reply to paul from comment #83) > You guys are awesome! Based on "Target Milestone: mozilla21" we should see > this around May 2013, right > (https://wiki.mozilla.org/RapidRelease/Calendar)? Or could we patch it in > earlier? +1, to both, awsome work and pls consider landing this on Aurora. I'm aware we'll be caught between a rock and a hard place, i.e. between - the legitimate desire to let this bake well to avoid more unforeseen trouble, - vs. the pressing need for users to get this fixed asap because it can break entire editing systems. So if there's any way we could responsibly have this on Aurora, pls do.

Nominating for Aurora inclusion...

Presume this will get to Thunderbird in builds as well as Firefox?

Verified fixed in Thunderbird using TB tinderbox Built from http://hg.mozilla.org/mozilla-central/rev/a46bc920998d using Thomas D's STR from comment 33

(In reply to Jet Villegas (:jet) from comment #85) > Nominating for Aurora inclusion... Given this is a longstanding issue, no need to track for release. Please nominate for uplift with a risk evaluation, so we can evaluate risk/benefit.

I'm glad to see this will finally be fixed. I've had this issue for a few versions of Thunderbird and today decided to test the issue for myself. Sure enough, after sending a message to myself that had had partially underlined words I saw dozens of <font size="-1"> tags littered throughout. I'm curious: Will this bug fix also end up fixing the age-old problem where Thunderbird randomly changes font faces and sizes to match the email you're replying to when you get close to the quoted content in reply-above mode?

This is just reverting back to older behavior, so it probably won't fix any long-standing issues.

Can I clarify that - despite all the fantastic hard work and intensive team efforts in the last week to fix this long running bug that so many people are having user issues with - it will still be several months until it actually gets applied?? I *do* understand there must be a sense of due-process but to have such a critical bug affecting Moodle, Sakai, Drupal, and practically every web text editor you can think of - is disastrous. Can we get this inserted MUCH MORE QUICKLY PLEASE? It seems crazy that all that wonderful speed and effort is now going to sit around a server folder waiting? I checked for '81263' in the latest Version 19 that has just gone out but it was missing (or not added into that version) Please advise. I'm clearly not technical but waiting several months (May apparently?) to fix a critical flaw seems utterly without sense or merit. (P.S. For some reason I had to create an identical user account for this page to add this message - odd - do passwords and accounts expire after a couple of weeks)

(In reply to Dom London from comment #91) > Can I clarify that - despite all the fantastic hard work and intensive team > efforts in the last week to fix this long running bug that so many people > are having user issues with - it will still be several months until it > actually gets applied?? Not only it has already been applied, but this past night the code in question underwent the transition from "Daily" to "Aurora". In six weeks time it will be uplifted to "Beta", and the "Release" is six weeks later again. If you're hasty, you can get the latest Thunderbird-Aurora here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora/?C=M;O=D The part at the end starting with a question marks makes sure that the latest builds come at the top of the list. Be sure to download version 21.0a2 (not 20.0a2) and to select the right one for your operating system. Thunderbird 21 and later has the fix for this bug. [...] > (P.S. For some reason I had to create an identical user account for this > page to add this message - odd - do passwords and accounts expire after a > couple of weeks) Identical to what? AFAICT this comment is your only activity ever at bugzilla.mozilla.org with this account and email address. Normally, if you get logged out, you should be able to log in again: I've been using a single account without any trouble since July 2003.

I guess another six weeks is *slightly* better than eight weeks. but yes April may - it would indeed seem to be. Apologies but as an end user - I've been unable to figure out what Aurora is - Also Im referring to the users of Firefox, not the mail program. It's not that I am desperate to evaluate beta software. I *AM* keen however to get a proven fix adopted quicker than Spring 2013 given a) how long the bug has existed (2-3 months) and b) how many appilcations it directly effects (Ive listed a few in my earlier post) In the meantime, we'll all just hold out for Firefox v20 in Late April / May. It is what it is. And yes - bugzilla page here a) rejected the cached password and username and b) rejected my email address as the current account address held on the system - the only option was c) create a new account - if it turns out its the same one as before then I guess the email - account re-creation were more for the benefit of the server than the client ;-)

(In reply to Dom London from comment #93) > I guess another six weeks is *slightly* better than eight weeks. but yes > April may - it would indeed seem to be. > > Apologies but as an end user - I've been unable to figure out what Aurora is > - Also Im referring to the users of Firefox, not the mail program. Aurora is just a name for the second level of code development. You might call it "Alpha 2" if you understand that better, "Aurora" is just what it is called at Mozilla. Bleeding-edge code development is made on source repositories which are variously named "Nightly" for Firefox, "Daily" for Thunderbird or "Trunk" for SeaMonkey or historically for any Mozilla code. Nowadays, a copy of the current bleeding-edge code is taken every six weeks and becomes "Aurora", which in a nutshell means source code older than six weeks but not older than twelve. Six weeks later, Aurora goes to Beta (and isn't built every night anymore), and six weeks after that is the official release. In the meantime, after every Trunk → Aurora copy the bleeding-edge code version is increased by one. Since yesterday, the Thunderbird versions being developed are: 22.0a1 "Daily" 21.0a2 "Aurora" 19.0b1 is still the current "Beta" 17.0.3 is still the latest "Release" (apparently Thunderbird, having fewer developers than Firefox, misses some versions). But as I said, Thunderbird "Aurora" executables are already available with the fix for this bug. Since the code is "only" six weeks old, those builds might have some other bugs which haven't yet been discovered, but they have already reached a certain degree of "stability". The Summary of this bug mentions Thunderbird, so I supposed that was what you were interested in. For Firefox the system is the same if more regular: Firefox 22.0a1 "Nightly" is the bleeding-edge code with a new version number since today or maybe yesterday. Firefox 21.0a2 "Aurora" has cooked for six weeks as Nightly, then a copy was taken to a different source repository. You can get a Firefox package without this bug at this URL: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/?C=M;O=D but the same caveats apply: this is not yet a public release, it is feature-complete but possibly buggy, it is what I dubbed earlier an "alpha 2" though the official name is Aurora. Firefox 19.0b6 is still the latest Beta, but it is now obsolete, since… Firefox 19.0 has already been released. > > It's not that I am desperate to evaluate beta software. I *AM* keen however > to get a proven fix adopted quicker than Spring 2013 given a) how long the > bug has existed (2-3 months) and b) how many appilcations it directly > effects (Ive listed a few in my earlier post) > > In the meantime, we'll all just hold out for Firefox v20 in Late April / > May. It is what it is. Firefox 20 won't have the fix, unless the developers decide that it is urgent enough and port the fix from the Firefox 21 source branch (which now has the fix) to the Firefox 20 branch. Watch the "Tracking Flags" on the right side of this page above comment #0: "affected" means that the bug has been found in the concerned version. When the developers decide what to do about it, "affected" may change either to "wontfix", or else to "fixed" once the changes have been applied to the source of that version, and "fixed" may change again to "verified" once a tester has checked, by actually using the executable, that the fix works. > > And yes - bugzilla page here a) rejected the cached password and username > and b) rejected my email address as the current account address held on the > system - the only option was c) create a new account - if it turns out its > the same one as before then I guess the email - account re-creation were > more for the benefit of the server than the client ;-) Strange. And — sorry, developers, for the bugspam. I hope I didn't bore you too much.

Thank you for the time and trouble taken with your reply Tony

(In reply to Tony Mechelynck [:tonymec] from comment #92) > Not only it has already been applied, but this past night the code in > question underwent the transition from "Daily" to "Aurora". In six weeks > time it will be uplifted to "Beta", and the "Release" is six weeks later > again. > > If you're hasty, you can get the latest Thunderbird-Aurora here: > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm- > aurora/?C=M;O=D > The part at the end starting with a question marks makes sure that the > latest builds come at the top of the list. Be sure to download version > 21.0a2 (not 20.0a2) and to select the right one for your operating system. > Thunderbird 21 and later has the fix for this bug. Funny, I'm still seeing the bug present in Thunderbird 22.0a2 (2013-4-4). I do have my font set to the non default Helvetica, Arial. When I change the font back do the default variable width, I am no longer able to reproduce it. Does anyone else see this?

Seeing that as well on Seamonkey nightly (usually composing in HTML / Arial).

Hi Guys Come on guys. Where are we on this? Status shows verified fixed, so I'd really like this *IN* he updates. Ive just noticed that this same bug that utterly plagues users of Firefox with moodle, Desire2Learn, Drupal, Word Press (and which has forced me to abandon firefox in favour of chrome) is ALSO really messing up all my THunderbird emails. Messages look like they are sent by a five year old with fonts changing up and down throughout the message - and damaging my non profits reputation. I know that hard work and effort has gone into this fix, Im very grateful but - PLEASE - can we just side-step the "long wait until May" and GET THIS INTO the update process now. (I dont mean downloading or compiling code from some obscure develper website, im talking about from the "check for update software" from within the application. This is listed as a critical bug. I flagged this up in FEBRUARY, and Im sorry but in my very limited experienced opinion, (im simply an end user) you are killing Thunderbird and Firefox users and user-base. I really am fed up having to "clean up" all my thunderbird messages in a text editor so they dont all look retarded because of this bug. I'm sure my posting will not change any dates, but it will at least underscore the immense frustration of everyday users wanting to just FIX a massive hassle and terrible bug in the editor of Mozilla's TWO BIGGEST brand applications. Its shocking we're still waiting "out here"

I wholeheartedly agree. If it's any help: I've been able to circumvent this bug, at least in Thunderbird, by downgrading to Thunderbird 15. Which has other text composition bugs, but at least those are VISIBLE and can be fixed before hitting the send button. But having a real fix on the release update channel would be infinitely better of course :) It's indeed a very hurtful fact that there's months of versions of Thunderbird and Firefox that include this bug.

In reply co comment #99 and #100: see also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and in particular its points 1.1, 1.2 and 2.2. Developers, sorry for the bugspam.

In reply to comment 101 Developers - sorry for the troll-spam, see also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and in particular the fact that such comments have got absolutely didldy squat to do with points 1.1, 1.2 and 1.3 The Mozilla community does NOT STOP with hard working developers who give up much ime to make such tools available but also the end users - whose polite contribution you've self nominated to value-judge. So - 'Antoine' - until you're awarded the title "Defender of Humanity' can I invite you to forego sanctimonious self indulgent proxy 'faux" apologies and their rather insipid inferences? I say this because I suspect that the coders AND contributors on here are focussed on solving problems and probably not waiting for questionable value judgements disguised as some sort of unctuous, hagiography of a group of intelligent creatives who - I imagine - are perfectly capable of permitting polite comment and enquiry. Please see point 1.1 which thus - ironically - applies to your oen comment. Lets leave it there shall we? THough I suspect you wont...

There's only so much bugspam I can take. Unccing myself. :(

I second that.

(In reply to Alex Keybl [:akeybl] from comment #88) > (In reply to Jet Villegas (:jet) from comment #85) > > Nominating for Aurora inclusion... > > Given this is a longstanding issue, no need to track for release. Please > nominate for uplift with a risk evaluation, so we can evaluate risk/benefit. Some facts (provided by a volunteer who actively contributed to getting this highly annoying bug out of the way as quickly as possible, see my comments above): * The patch was nominated by the patch author for uplifting (releasing earlier, bypassing the usual baking period to ensure product quality) in comment 85. * There was an official response to that, requesting more information to "evaluate risk/benefit" before uplifting, comment 88. * Neither developers nor users did anything specifically to provide or kick-start that risk/benefit evaluation (E.g. as users, instead of general lamentation, we could have asked specifically who is able or willing to provide the evaluation requested in comment 88). * Due to the lack of risk/benefit evaluation, this could not be uplifted for earlier release. (And we wouldn't want more bugs / regressions being introduced because of skipping such precautions of due course, would we?) * The current release version of Firefox is 20.0.1 (released 2013-04-02). For this version, it is practically too late to get the fix included, because it has already been released. ******************************************************************************** * The next release version of Firefox, 21, will be released on 2013-05-14 (only 3 and a half weeks from the date of this comment), and it will include the fix for this bug (per Target milestone: mozilla21, see top of this bug). ******************************************************************************** * It's certainly appreciated by everyone involved including developers that users will be frustrated about this bug until the fix will be released, but unfortunately, *any further comments to that end are pointless* because they won't change the facts: Start counting today, only 25 days until landing of the fix. (And coming from a Thunderbird background, I've seen lots of bad bugs taking much longer than this one - 6 months from the date of reporting is actually quite quick in the broad scheme of things, considering how many other bugs are out there and users also rightly want to see them fixed...) * Finally, especially for the majority of us who can't fix those bugs themselves, let's be thankful for the work of those who fix them, and then offer their improved software products to us for free.

FTR: Firefox Rapid Release Schedule/Calendar lives here: https://wiki.mozilla.org/RapidRelease/Calendar (In reply to Thomas D. from comment #105) > * The current release version of Firefox is 20.0.1 (released 2013-04-02). > For this version, it is practically too late to get the fix included, > because it has already been released. > > ***************************************************************************** > * The next release version of Firefox, 21, will be released on 2013-05-14 > (only 3 and a half weeks from the date of this comment), and it will include > the fix for this bug (per Target milestone: mozilla21, see top of this bug). > *****************************************************************************

Allow me just one more comment to help impatient individuals (like me) seeking to get the fix earlier, despite all previous comments: you can always use the beta version that was released 10 days ago. Lightning (the Calendar addon) has a matching beta version since 6 days ago, and if you use any other essential addons you should of course check those first too. I personally also needed an early release of Provider for Google Calendar. This may not be a viable option for companies, but it probably is for individuals. It's certainly working great for me now! Makes me happy. I hope this comment may help some other people become happy, too. - Download Thunderbird 21.0b1 (or later) from https://www.mozilla.org/en-US/thunderbird/all-beta.html - (optional) Download Lightning 2.3b (or later) from https://addons.mozilla.org/en-US/thunderbird/addon/lightning/versions/ - (optional) Download Provider for Google Calendar 0.21pre (or later) from https://addons.mozilla.org/en-US/thunderbird/addon/provider-for-google-calendar/versions/ This way, you don't have to wait for the fix to land on the release channel. You can then move back to that channel on May 14th.

(In reply to Joris Debonnet from comment #107) > Allow me just one more comment to help impatient individuals (like me) > seeking to get the fix earlier, despite all previous comments: you can > always use the beta version that was released 10 days ago. Lightning (the > Calendar addon) has a matching beta version since 6 days ago, and if you use > any other essential addons you should of course check those first too. I > personally also needed an early release of Provider for Google Calendar. > > This may not be a viable option for companies, but it probably is for > individuals. It's certainly working great for me now! Makes me happy. I hope > this comment may help some other people become happy, too. > > - Download Thunderbird 21.0b1 (or later) from > https://www.mozilla.org/en-US/thunderbird/all-beta.html > - (optional) Download Lightning 2.3b (or later) from > https://addons.mozilla.org/en-US/thunderbird/addon/lightning/versions/ > - (optional) Download Provider for Google Calendar 0.21pre (or later) from > https://addons.mozilla.org/en-US/thunderbird/addon/provider-for-google- > calendar/versions/ > > This way, you don't have to wait for the fix to land on the release channel. > You can then move back to that channel on May 14th. And if you're the patient type, but still want your messages to look good before you send them: 1. Select the content of your message 2. Go Format > Font, and select the desired font 3. Go Format > Size, and select the desired size This should 'normalize' the appearance of your response.

I find that Format > Size does not necessarily work in replies. What is reported as "Small" is sometimes larger and sometimes smaller. I can at least assure that everything in my reply is ONE size by selecting my entire reply, cutting it to the clipboard, pasting it back in with Ctrl-Shift-V (aka Edit: Paste Without Formatting), then reapplying any formatting.

Hi I encounter similar issue with one of my user : - Windows 7 - Thunderbird 17.0.6 ESR Seems that text have random size in his mail with lots of tag: - <font size="-1"> - <span size="-1"> I remark also spelling issues Is there a way to bypass this bug temporaly thank

(In reply to narutobaka from comment #110) > Is there a way to bypass this bug temporaly Make sure the font size is set to "medium" in the composition preferences and instruct your user not to use the font size buttons in the composition window.

Am I mistaken in thinking that this has yet to be included in a release of Thunderbird? I've been watching this bug for months, and still using TB 15 because of this bug (and yes I am aware of the workarounds). I know there are many hardworking and talented people volunteering their time; thank you.

Seconded. This awful bug has been kicking around Thunderbird for nearly a year. I too thought it was fixed but still await its insertion, as the myriad of Firefox releases swim by.... Baffling..

It should be fixed in Thunderbird 24 (which will be released very soon) as far as I see this.

I have been running TB24 nightly for quite a while and not had any real issues recently - and last night moved to TB25 nightly and it seems fixed there. As per comment #114 it looks like when TB24 is released this issue should be resolved.

In the nicest way possible, I think it is fair to point out that those of us fortunate enough not to have to do all the actual hard work of fixing this nasty bug, have been told since March that a "fix was coming" at Version XYZ for a very long time. It has rather been "just around the corner" for more than 8 months, the most recent undertaking being a "fix and release by May/June" Is there any way to be a little more specific than "very soon"? I long for the day (without dailies, nightlies, naughties etc) when the most fundamental task of an email program - to be to simply write text without "code introduced" numerous glitches, typos, font size changes and much else. Perhaps we can add a function to bug reporting that says FIXED BUT PENDING UPDATE? With continuing thanks for all the hard work.

Dom London, My "issues" have been similar to the title of this bug but have varied somewhat and I've always stayed up to date with the "release" versions. First, TB has been having this issue on my computer for closer to 2 years. Second, my issue for quite a while has been spell check not working correctly. A word would be underlined after I typed it wrong but if I didn't go back to the word and correct after about 5 seconds, the red squiggly underline would disappear and I would not have a visual indication any more that the word was misspelled. It was VERY annoying especially if writing a long email. BUT...I noticed this morning that V24 was available and I updated. I did some tests and from what I can see, my problems are all fixed! Upgrade to V24 and see if your problem goes away.

(In reply to Dom London from comment #116) > In the nicest way possible, I think it is fair to point out that those of us > fortunate enough not to have to do all the actual hard work of fixing this > nasty bug, have been told since March that a "fix was coming" at Version XYZ > for a very long time. It has rather been "just around the corner" for more > than 8 months, the most recent undertaking being a "fix and release by > May/June" > > Is there any way to be a little more specific than "very soon"? I long for > the day (without dailies, nightlies, naughties etc) when the most > fundamental task of an email program - to be to simply write text without > "code introduced" numerous glitches, typos, font size changes and much else. > Perhaps we can add a function to bug reporting that says FIXED BUT PENDING > UPDATE? > > With continuing thanks for all the hard work. RESOLVED FIXED means fixed in the bleeding-edge development version of the source, which produces Daily builds of Thunderbird, Nightly builds of Firefox, and Trunk builds of SeaMonkey, all with version numbers ending in a1. These builds are available to anyone who wants to test them, but there could be other bugs in them, and they are definitely not meant for professional use. So you should weigh how eager you are to get the executable where one particularly itching bug has just been fixed, against the risk that other bugs are still sleeping, yet unknown, in the same executable, just waiting to bite you. If you are daring enough, or eager enough, the various versions of Thunderbird executables can be found at the following addresses: - the latest "extended support" release for corporations: http://www.mozilla.org/en-US/thunderbird/organizations/ (that link gives access to builds in all available languages, and anyone can get them for free, but they're usually somewhat older than even the "latest stable", and not recommended for home users) - the latest "stable" release: http://www.mozilla.org/en-US/thunderbird/ - the latest "beta" release (there is *not* always one for the next version after the "current stable", so check the version number): http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/latest-beta/ - the latest "Aurora" build: - with English (US) menus and messages: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora/ - other languages: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora-l10n/ - the latest "Daily" build: - English (US): http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ - other: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-l10n/ Of course ONLY the stable release is recommended for normal users; the rest are meant for TESTING, and probably contain more bugs that are not fixed yet, or possibly not even found yet. If you decide to bypass this warning anyway, it is entirely your responsability. YOU'VE BEEN WARNED! After baking for six weeks on a given source repository, the source code is moved to the next one in turn: the previous Beta source goes to Release, then shortly after that the previous Aurora becomes the new Beta, then the previous Daily/Nightly/Trunk becomes the new Aurora, so that it takes between 3 and 4½ months for a given bugfix to progress to a "stable release".

Sadly in this case this bug has taking (and is still taking) something like 7 months and counting to reach the light of day. Will it ever happen?

Dom, did you already upgrade to version 24? It was released about a week ago, and contains the fix for this bug. It may not make the composer editor a state-of-the-art one, but it certainly does fix this particular bug. The source code of my emails has been clean since I started using this version.

Hi Joris Yes, using version 24, and a year after I raised this bug, I'm still using an email program that turns every over word in a jumble of differently sized fridge poetry. I've followed all the advice, waited for all the promises, but I have o admit, at this late stage the problems it is causing with how badly my business and personal emails are appearing to colleagues is sorely testing my loyalty to FF and TB. After an extraordinarily long wait, I *just* want to know when this "email compose" bug - which is surely a critical issue as it goes he core of the functionality of the software - will be introduced, that's all. In all fairness, I'm going to have to resort of Outlook if we reach the first anniversary of this discussion thread.

Appreciate the frustration, but enough with the comments here. So that we can all be productive, file a new bug please or move on to a relevant still open bug<EOM>

Hi Wayne - I think Joris was just trying to be helpful there ;-) (And I'm just saying a year is probably long enough to wait for a fix)

(In reply to Frank Wein [:mcsmurf] from comment #114) > It should be fixed in Thunderbird 24 (which will be released very soon) as > far as I see this. Adding end-user technical validation, I can confirm through independent experience that TB 24.0 under Windows 7 x64 has resolved this issue completely. Prior to the upgrade, viewing the HTML source of a sent message would show a pseudo-random mess of "font size=" entries. With TB 24.0, the sent HTML is perfectly clean with only one font size directive inserted at the beginning of the reduced size text. - Dave

Unfortunately, Im using V 24 for MAC, and it isnt resolved.

I'm also still seeing it as a bug using Windows 7 x64 and version 24.

Someone file a new bug for this, please?

Im a bit confused, but that is Im sure because I am one of those awful end users types who Im sure should not be here. (waits for the flamewars!) However I would humbly suggest that simply correcting this entry to NOT fixed, is not only the simplest thing to do, it strikes me as a clearer, more transparent was to complete the story, rather than start a fresh one nearly a year on for this unfixed bug? IMHO - I'm going to look at any updates / fixes in October and if I'm still typing fridge-magnet poetry with crazy font size changes then, with every possible respect to the immense amount of hardwork I know has been invested, I'm going to have to bow out and switch to a working email app. Please dont take offense. Its not intended. It is just feedback from the end-user base, and Im sure there should always be a polite window for that voice. If this isnt the right forum, then understood, and apologies offered. But I must leave it and my (basic) testing feedback there.

(In reply to comment #128) > However I would humbly suggest that simply correcting this entry to NOT fixed, > is not only the simplest thing to do, it strikes me as a clearer, more > transparent was to complete the story, rather than start a fresh one nearly a > year on for this unfixed bug? That's now how our process for managing bugs works. We usually don't reopen a bug unless its patches have been reverted. Please file a new bug with the *exact* steps to reproduce this bug. Thanks!

(In reply to Dom London from comment #128) > Im a bit confused, but that is Im sure because I am one of those awful end > users types who Im sure should not be here. (waits for the flamewars!) > > However I would humbly suggest that simply correcting this entry to NOT > fixed, is not only the simplest thing to do, it strikes me as a clearer, > more transparent was to complete the story, rather than start a fresh one > nearly a year on for this unfixed bug? > [...] As per bug description (reproduction procedure) and subsequent comments, this bug has nothing to do with your "fridge-magnet poetry with crazy font size changes". See e.g. following instead: bug 606668 bug 799893 bug 617878 or look for / submit another bug. Another End User

See comment 131 Im using Thunderbird V 24 the 24.0 release with Windows XP. The "check spelling as you type" option checked, no longer works : the wrong words are not underlined. See the attached screen copy. JF Petit

Yes, I'm seeing this too (Windows Vista; TB 24.0). I was planning to check our other systems before commenting (we're on hols just now). If this is a generic problem with 24 it's a bit of a disaster. If a new bug report is raised, please post the number here so I can follow it.

Please file new bugs - that is hardly related. (And seems to work ok for me, make sure the correct language is checked in the Spelling toolbar button menu.)

Just upped to 24.0 yesterday on Win 7. Now spell checking doesn't work... The correct language is selected (though, in the case of PETIT's SpellCheck.jpg, surely there's no language that counts "fhhjkl" as a correctly spelled word?!) Off to look for new bugs to vote for...

No Im sorry but the language (French) is selected. JF Petit

FFS, PLEASE FILE A NEW BUG :) the developers will ignore you and your comments. Open a new bug! It's the only way to get some attention to this. Go here --> https://bugzilla.mozilla.org/enter_bug.cgi <--

I believe your issues are being addressed in bug 917027 which can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=917027 I recommend going there and voting for the bug to increase it's attention to the Devs.

I added a comment to the Bug 919184

(In reply to PETIT from comment #138) > I added a comment to the Bug 919184 Suggest you add your comments re. 'check spelling as you type' to bug 917027 (see comment #137 above), as 919184 is listed as a 'duplicate' of 917027.

I added a comment to the bug 917027 too. I'm afraid we also have to wait almost a year for this new bug is fixed?

LOL. I hope not...although it is rather comical that something as basic as spell check and email composition has been such a thorn in TB's side. I'm sure it's not as simple as it sounds but they just can't seam to get it straight.