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.
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
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).
Created attachment 556487 [details] [diff] [review] patch proposal patch proposal. try server log for that patch: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=45ae4267170b
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.
Created attachment 557474 [details] [diff] [review] updated patch updated patch to change variable name
In my queue :-)
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
http://hg.mozilla.org/integration/mozilla-inbound/rev/9ef862cbcc5e
Backed out of mozilla-inbound because of mochitest-oth oranges like this: https://tbpl.mozilla.org/php/getParsedLog.php?id=6237599
Strange, didn't show on the try run (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=984e63e9170b), presume intermittent.
Created attachment 557820 [details] [diff] [review] patch fixing wrong variable >+ // 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
http://hg.mozilla.org/integration/mozilla-inbound/rev/d09cbf88c277
http://hg.mozilla.org/mozilla-central/rev/d09cbf88c277
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
I'm seeing this problem once again? I've just had to switch Yahoo mail back to en-GB twice in the same session.
(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?
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
Do you have steps to reproduce?
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
(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!
(Clearing to stop this request showing up on the 'My Requests' page)
I am also getting the language seemingly inconsistently reverting back to English (US) from English (UK). Can anyone link to a new bug report?
A number of bugs on this theme have been raised. I've just created a tracker: bug 1073827
or
