User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110223 Firefox/4.0b13pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110223 Thunderbird/3.3a3pre The summary says it all. Once really disabled by enabling and disabling again in the subject line of a message compose window (plain text or HTML), "spell check as you type" remains disabled until Thunderbird is restarted. This bug is a spin-off from bug 369104. Reproducible: Always Steps to Reproduce: 1. Disable "spell check as you type" globally. 2. Restart Thunderbird. 3. Start writing a new message and type some nonsense words into the subject line. Actual Results: The misspelled words are underlined. Expected Results: The misspelled words are not underlined because "spell check as you type" is disabled. Regression window: <http://hg.mozilla.org/comm-central/pushloghtml?startdate=2010-06-07+14%3A50&enddate=2010-06-09+02%3A00> which looks for me as if due to <http://hg.mozilla.org/comm-central/rev/c350165913d0> some incompatible Gecko changes broke things in Thunderbird, but this is just my uneducated guess.

comm-1.9.1 and comm-1.9.2 branches are not affected.

perhaps something checked in to core - several spell checkins per http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-06-07+14%3A50&enddate=2010-06-09+02%3A00

(In reply to comment #2) > perhaps something checked in to core - several spell checkins per > http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-06-07+14%3A50&enddate=2010-06-09+02%3A00 The only thing which jumps at me in this range is bug 570350, but that has also landed on 1.9.1 and 1.9.2, so I think if that bug was to blame, this problem would happen on those branches as well. Can someone bisect the comm-central and mozilla-central ranges, please?

Also, can someone post an mxr link to the xul element corresponding to the subject text box in question?

Hmm, for me, on 1.9.2, spell checking is enabled by default on that field. Am I missing something?

(In reply to comment #5) > Hmm, for me, on 1.9.2, spell checking is enabled by default on that field. Am > I missing something? The issue is not the default setting. For me, if mail.spellcheck.inline is set to 'false' by the user, the spell checker on 1.9.2 doesn't underline misspelled words in the subject line, which is the correct behavior. It does underline them on trunk, but only just this: right-clicking an underlined misspelled word doesn't show a list of suggestions. To hide annoying red waved lines, one has to *enable* inline spell checker globally, and then *disable* it from the *context menu* of the subject line text field each time one starts writing a message. I'm sorry for not having mentioned this detail in the initial bug description.

I left comm-central revision at <http://hg.mozilla.org/comm-central/rev/c350165913d0> (first bad official Thunderbird nightly) and bisected mozilla-central. The results after 9 iterations are: last good m-c revision: <http://hg.mozilla.org/mozilla-central/rev/21f0727c27a6> first bad: <http://hg.mozilla.org/mozilla-central/rev/2437636244f3> (with the patch <http://hg.mozilla.org/mozilla-central/rev/2875f9a693ae>) => Bug 534785

(In reply to comment #4) > Also, can someone post an mxr link to the xul element corresponding to the > subject text box in question? <http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul#713> Disclaimer: I don't understand XUL and had to rely purely on common sense. This said, the link above may be plain wrong.

Yes, this is indeed a regression from bug 534785, and I've managed to reproduce it locally. Here is what's happening. The textbox.xml binding is initializing the spellcheck attribute on the HTML input element explicitly. When the input-box-spell is applied to the parent node of the HTML input by inheriting the spellcheck attribute from the textbox element, we call into the editor directly to enable spell checking, which sets mSpellcheckCheckboxState to eTriTrue. Later, we reuse the same editor object, which has the mSpellcheckCheckboxState member set, which causes us to turn on spell checking even though the spellcheck attribute is now false. We didn't hit this bug before since a new editor object would get created as part of the reframe, which would cause us to start with a fresh mSpellcheckCheckboxState. The fix is very simple, we should just set mSpellcheckCheckboxState to eTriUnset in the PreDestroy function so that its value doesn't persist needlessly across reframes. I have a patch which does that.

http://hg.mozilla.org/mozilla-central/rev/5b9b948eb717 Ilja, I'd appreciate if you can test the tomorrow's Thunderbird nightly to make sure that this bug has indeed been fixed.

(In reply to comment #11) > http://hg.mozilla.org/mozilla-central/rev/5b9b948eb717 > > Ilja, I'd appreciate if you can test the tomorrow's Thunderbird nightly to make > sure that this bug has indeed been fixed. This won't be in Thunderbird's nightly tomorrow due to bug 636795 / bug 637876.

(In reply to comment #11) > http://hg.mozilla.org/mozilla-central/rev/5b9b948eb717 > > Ilja, I'd appreciate if you can test the tomorrow's Thunderbird > nightly to make sure that this bug has indeed been fixed. I've tested the patch with my local Thunderbird build immediately as I got the bug mail and it fixes the issue, thank you very much for the instant solution. Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110301 Thunderbird/3.3a3pre built from <http://hg.mozilla.org/comm-central/rev/09885f20326f> and <http://hg.mozilla.org/mozilla-central/rev/30d4fd4a62d2> with the patch <https://bugzilla.mozilla.org/attachment.cgi?id=515858> on top. I haven't hit the crash mentioned in Comment #12 yet.

Thanks for helping me figure this out, Ilja!