Closed
Bug 682564
Opened 11 years ago
Closed 11 years ago
Dictionary keeps switching to en-US despite being set otherwise
Categories
(Core :: Spelling checker, defect)
Core
Spelling checker
Tracking
()
RESOLVED
FIXED
mozilla9
People
(Reporter: pwd.mozilla, Assigned: arno)
References
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
3.45 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110826 Firefox/9.0a1 Build ID: 20110826030805 Steps to reproduce: If you set the dictionary to en-GB (for example), you'll find that it keeps setting itself back to en-US.
Reporter | ||
Updated•11 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
Updated•11 years ago
|
Blocks: 338427
Component: General → Spelling checker
Keywords: regression
Product: Firefox → Core
QA Contact: general → spelling-checker
I can confirm this. STR is 1:Install another spellcheck Dictionary.(In my case en-AU)Switch to it. 2:Close browser and on re-start the Dictionary will hve chang3ed back to the en-US default one. 3:Expected behaviour is the spellcheck dictionary should remain on the language the user selected. I also checked the about:config setting and spellchecker.dictionary; is set to en-AU
Assignee | ||
Comment 2•11 years ago
|
||
Since bug 338427, spellcheck language is set automatically, depending on the page (or the editable element) language. So, if a page tells it's en-US, spellchecker will be set to en-US. Last dictionary set manually is only used in case the page does not specify a language. But, page may specify a language-region which no installed dictionaries can handle. For example, it may specify "en" or "en-NZ". If you have "en-US" or "en-AU", spellchecker currently picks one of them at (nearly) random. This could be improved by preferring, in that specific case, language set in spellchecker.dictionary (ie: last language set manually).
Assignee | ||
Comment 3•11 years ago
|
||
patch proposal. try server log for that patch: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=45ae4267170b
Attachment #556487 -
Flags: review?(ehsan)
Updated•11 years ago
|
Assignee: nobody → arno
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 4•11 years ago
|
||
Comment on attachment 556487 [details] [diff] [review] patch proposal Review of attachment 556487 [details] [diff] [review]: ----------------------------------------------------------------- ::: editor/composer/src/nsEditorSpellCheck.cpp @@ +728,5 @@ > dictName.Assign(mPreferredLang); > } > > // otherwise, get language from preferences > + nsAutoString aPreferedDict(Preferences::GetLocalizedString("spellchecker.dictionary")); Please use preferredDict instead.
Attachment #556487 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 5•11 years ago
|
||
updated patch to change variable name
Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Updated•11 years ago
|
Attachment #556487 -
Attachment is obsolete: true
Comment 7•11 years ago
|
||
With a few other bits that are being sent to try first and then onto inbound: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=984e63e9170b
Comment 8•11 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/9ef862cbcc5e
Target Milestone: --- → mozilla9
Comment 9•11 years ago
|
||
Backed out of mozilla-inbound because of mochitest-oth oranges like this: https://tbpl.mozilla.org/php/getParsedLog.php?id=6237599
Target Milestone: mozilla9 → ---
Comment 10•11 years ago
|
||
Strange, didn't show on the try run (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=984e63e9170b), presume intermittent.
Assignee | ||
Comment 11•11 years ago
|
||
>+ // Otherwise, try langCode (if we haven't tried it already) >+ if (NS_FAILED(rv)) { >+ if (!dictName.Equals(langCode) && !preferedDict.Equals(langCode)) { >+ rv = SetCurrentDictionary(preferedDict); >+ } >+ } Oups, this was caused by a typo. langCode (editor language without region) was tested, and preferedDict (last dictionary set in prefs) was used. Test may succeed accidentally in case there is no preference set. But if a preference is set, the test will fail. That may explain the difference try server and inbound. I'll ask for review, or flag this patch as checkin-needed if try server results are correct for this patch https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=2d7df6f7fb41
Attachment #557474 -
Attachment is obsolete: true
Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Comment 12•11 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/d09cbf88c277
Flags: in-testsuite?
Keywords: checkin-needed
Updated•11 years ago
|
Target Milestone: --- → mozilla9
Comment 13•11 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d09cbf88c277
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 14•11 years ago
|
||
Try run for 2d7df6f7fb41 is complete. Detailed breakdown of the results available here: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=2d7df6f7fb41 Results (out of 236 total builds): success: 223 warnings: 12 failure: 1 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/arno@renevier.net-2d7df6f7fb41
Reporter | ||
Comment 15•11 years ago
|
||
I'm seeing this problem once again? I've just had to switch Yahoo mail back to en-GB twice in the same session.
Comment 16•11 years ago
|
||
(In reply to Paul [sabret00the] from comment #15) > I'm seeing this problem once again? I've just had to switch Yahoo mail back > to en-GB twice in the same session. Which version of Firefox did you see it in?
Comment 17•11 years ago
|
||
Has happened twice to me today whilst composing two separate gmail emails. It's possible the session was restarted in-between (sorry can't remember). Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120111 Firefox/12.0a1
Comment 18•11 years ago
|
||
Do you have steps to reproduce?
Comment 19•11 years ago
|
||
I haven't been able to get it to occur consistently, but they are along the lines of (using British English dictionary + Nightly): 1) In a gmail app-tab start new draft email 2) Type a word that has a different spelling in the US eg neighbour 3) Spot that the word is marked as misspelt, check context menu - find it is set to US English 4) Set back to UK English 5) Finish email + send, return to gmail inbox 6) Carry on browsing, restart session at some point. 7) Repeat steps 1-6 again
Comment 20•11 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #19) > I haven't been able to get it to occur consistently, but they are along the > lines of (using British English dictionary + Nightly): > 1) In a gmail app-tab start new draft email > 2) Type a word that has a different spelling in the US eg neighbour > 3) Spot that the word is marked as misspelt, check context menu - find it is > set to US English > 4) Set back to UK English > 5) Finish email + send, return to gmail inbox > 6) Carry on browsing, restart session at some point. > 7) Repeat steps 1-6 again Hmm, can you please file a new bug about this? This needs to be debugged and discussed separately. Thanks!
Comment 21•10 years ago
|
||
(Clearing to stop this request showing up on the 'My Requests' page)
Flags: in-testsuite?
Comment 22•9 years ago
|
||
I am also getting the language seemingly inconsistently reverting back to English (US) from English (UK). Can anyone link to a new bug report?
Comment 23•8 years ago
|
||
A number of bugs on this theme have been raised. I've just created a tracker: bug 1073827
Updated•7 years ago
|
See Also: → spell-lang-change
You need to log in
before you can comment on or make changes to this bug.
Description
•