Closed Bug 1073936 Opened 10 years ago Closed 10 years ago

Spelling not updated when spelling dictionary is changed

Categories

(Thunderbird :: Message Compose Window, defect)

31 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jorgk-bmo, Unassigned)

Details

(Keywords: intl, regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140923175406 Steps to reproduce: This didn't happen in 24.6. 1. Write a message in language 1. Set spelling to language 1. 2. Reuse a message in language 2 (Edit as new). Lots of errors are marked, since the dictionary is set to language 1. 3. Set spelling to language 2. Spelling mistake marks (underlines) are not removed. Actual results: Spelling mistake marks (underlines) are not removed. Expected results: Spelling mistake marks (underlines) should have been removed. I'm filing this as a new bug although this issue seems to raise its ugly head here and there. There is a bug 315784 from 2005 (!!), but this behaviour is clearly new.
Another case just happened: Write two messages at the same time in two languages: 1. Start message 1 in English 2. Start message 2 in Spanish 3. Return to message 1, send 4. Come back to message 2, now showing spelling mistakes, since the dictionary is still English. 5. Set dictionary to Spanish, underlines don't disappear. Well, sometimes they do, sometimes they don't. It's at random.
Another reproducible case: 1. Write a message in language 1. Set spelling to language 1. 2. Forward in language 2. Lots of errors are marked, since the dictionary is set to language 1. 3. Set spelling to language 2. Spelling mistake marks (underlines) are not removed.
Another reproducible case: 1. Write a message in language 1. Set spelling to language 1. 2. Reply to a message in language 2. Lots of errors are marked, since the dictionary is set to language 1. 3. Set spelling to language 2. Spelling mistake marks (underlines) are not removed. Whatever was done in 31: It's badly messed up now. Not good :-(((
Thanks for filing the new bug, I was going to suggest it in bug 315784 bug 959785?
Are you asking me whether this has to do with the problem described in bug 959785? Frankly, I don't know. The other bug is from Jan 2014, and it's unknown to which version it refers. The other bug seems to have to do "input element ... focus". This bug here doesn't. Select a different dictionary and the underlines aren't removed. Reproducible in the three scenarios "Edit as new", "forward" and simply "Reply", on a new message, the result seems to be random. This is new in 31, I used 24.6 before. Happens on Linux, too. I went back to 24.8 and 24.6 on Windows and Linux respectively since the bug is just too annoying to tolerate. [To downgrade on an Ubuntu-based Linux, download the 24.6 versions from here: http://security.ubuntu.com/ubuntu/pool/main/t/thunderbird/, then install with the Package Installer. You might also need a language pack. It took me a while to work this out, so I'm publishing it here]
Severity: normal → major
This is a major bug according to the definition: "major loss of function". It affects sending e-mail in more than one language, so about - at a guess - one third of all users worldwide. On of the beauties of TB is being having access to a variety of dictionaries with just a click. This function has become useless through this bug. It is quite an embarrassing regression. Reverting back to a version that works (24.x) is a major hassle. Please get the person who made changes to the spelling functionality - which worked with a few minor problems - to fix this major problem.
Perhaps it's about time the spell checking problems got cleaned up. There are many issues: https://bugzilla.mozilla.org/show_bug.cgi?id=368915 - still open https://bugzilla.mozilla.org/show_bug.cgi?id=717292 - waiting for the next one https://bugzilla.mozilla.org/show_bug.cgi?id=967494 https://bugzilla.mozilla.org/show_bug.cgi?id=714439 - still an issue? https://bugzilla.mozilla.org/show_bug.cgi?id=433181 - still an issue?
It will greatly help if you can please find the first daily comm-central build that demonstrates the problem. This will help us identify the code change which caused the problem. To find the first daily build that fails, you will want to start with the date range that we know, but which is to big: A. first 25.0a1 build https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013/06/2013-06-25-03-12-45-comm-central/ (will likely work) and ... B. last version 31.0a1 build https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2014/04/2014-04-29-03-02-01-comm-central/ (will likely fail). You will want to gradually narrow the regression range by starting with the midpoint C, between A and B, being roughly 2013-11-25 build. If C. fails then you will want to bisect the daily builds between A and C. And continue the bisect process until builddate+1 fails, and builddate works. Note, you won't a -comm-central/ build for every date, because on some days the development tree is broken.
https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013/12/2013-12-17-03-02-02-comm-central/ still working on the 17th Dec 2013. No version on the 18th Dec 2013. https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013/12/2013-12-19-03-02-02-comm-central/ Not working. Hooray, it went broken between the 17th and 19th of December, as a birthday present to me (DOB: 18th Dec.)
And how do we find the needle in the haystack?
(In reply to Jorg K from comment #14) > https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013/12/2013-12- > 17-03-02-02-comm-central/ > still working on the 17th Dec 2013. > > No version on the 18th Dec 2013. > > https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013/12/2013-12- > 19-03-02-02-comm-central/ > Not working. > > Hooray, it went broken between the 17th and 19th of December, as a birthday > present to me (DOB: 18th Dec.) Nice work!. THanks for doing that. (In reply to Jorg K from comment #16) > And how do we find the needle in the haystack? We wait til someone figures out which of the bugs in http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-12-17+03%3A00&enddate=2013-12-19+04%3A00 caused the problem and/or figures out how to fix it. It's too bad the build from the 18th is broken. And, much of those checkins are android/b2g and so most of those will have had no impact. But still a mess of changes and skimming the list nothing jumps out at me except bug 949445. The common central checkin list is uninteresting http://hg.mozilla.org/comm-central/pushloghtml?startdate=2013-12-17+03%3A00&enddate=2013-12-19+04%3A00 except for Bug 842632 - Improve the nsIMsgHeaderParser interface (bingo?)
Flags: needinfo?(mkmelin+mozilla)
Nothing jumps out at me. I doubt it could be from bug 842632.
Flags: needinfo?(mkmelin+mozilla)
(In reply to Wayne Mery (:wsmwk) from comment #17) > We ***wait*** til someone figures out which of the bugs in ... Sounds like ... https://www.youtube.com/watch?v=x_iPvUWyzhE
Shooting the video I noticed the following: If you're switching to the default language, the underlines go away. If you're switching to a different language, here Spanish, they don't go away. If you make another window current, the underlines get removed.
If someone believes this to be a core bug please move it to the right component and explain why this is a core bug, and CC me. I am not familiar with what Thunderbird does on top of core here.
Sorry, it's beyond me to know what is "core" and what is Thunderbird specific. If you watch the video closely, you can see that when switching the dictionary (to Spanish) the words "on" and "wrote" get marked as spelling mistakes. Sadly the Spanish words do not get unmarked. So either the "core" function of fixing up the entire text is not working or Thunderbird uses/calls this core function incorrectly. Sorry, only second-guessing.
I tried the current version https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2014/10/2014-10-06-03-02-02-comm-central/ There the problem doesn't exist. Now, do we go bisecting again to find the version where it got fixed?
Must have been a mozilla-central change then. In that timeframe I see this (that likely fixed it?) http://hg.mozilla.org/mozilla-central/rev/d774d2c87e78 Blake Kaplan — Bug 1031440 - Start moving mozInlineSpellChecker off of nsIDOM* APIs. r=ehsan
And can you see were it broke between 17th and 19th Dec. 2013?
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: