636465 - misspelled words in the subject line get underlined despite disabled "Spell Check As You Type" in a message compose window, have to turn it on and off to disable it for real

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Ilja Sekler]

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.

Comment 1

[Ilja Sekler]

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

Comment 2

[Wayne Mery (:wsmwk)]

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

Comment 3

[(no longer active)]

(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?

Comment 4

[(no longer active)]

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

Comment 5

[(no longer active)]

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

Comment 6

[Ilja Sekler]

(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.

Comment 7

[Ilja Sekler]

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

Comment 8

[Ilja Sekler]

(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.

Comment 9

[(no longer active)]

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.

Comment 10

[(no longer active)]

Attachment: Patch (v1)

Comment 11

[(no longer active)]

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.

Comment 12

[Mark Banner (:standard8)]

(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.

Comment 13

[Ilja Sekler]

(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.

Comment 14

[(no longer active)]

Thanks for helping me figure this out, Ilja!