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

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.

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

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.

>+ // 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

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