682564 - Dictionary keeps switching to en-US despite being set otherwise

Status: RESOLVED FIXED

Description

[Paul [pwd]]

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.

Comment 1

[M** A****]

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

Comment 2

[arno renevier]

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

Comment 3

[arno renevier]

Attachment: patch proposal

patch proposal.

try server log for that patch:
http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=45ae4267170b

Comment 4

[:Ehsan Akhgari]

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.

Comment 5

[arno renevier]

Attachment: updated patch

updated patch to change variable name

Comment 6

[Ed Morley [:emorley]]

In my queue :-)

Comment 7

[Ed Morley [:emorley]]

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

[Ed Morley [:emorley]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/9ef862cbcc5e

Comment 9

[:Ehsan Akhgari]

Backed out of mozilla-inbound because of mochitest-oth oranges like this:

https://tbpl.mozilla.org/php/getParsedLog.php?id=6237599

Comment 10

[Ed Morley [:emorley]]

Strange, didn't show on the try run (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=984e63e9170b), presume intermittent.

Comment 11

[arno renevier]

Attachment: 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

Comment 12

[Ed Morley [:emorley]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/d09cbf88c277

Comment 13

[Ed Morley [:emorley]]

http://hg.mozilla.org/mozilla-central/rev/d09cbf88c277

Comment 14

[Mozilla RelEng Bot]

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/[e-mail]-2d7df6f7fb41

Comment 15

[Paul [pwd]]

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

[:Ehsan Akhgari]

(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

[Ed Morley [:emorley]]

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

[:Ehsan Akhgari]

Do you have steps to reproduce?

Comment 19

[Ed Morley [:emorley]]

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

[:Ehsan Akhgari]

(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

[Ed Morley [:emorley]]

(Clearing to stop this request showing up on the 'My Requests' page)

Comment 22

[ronfrancis]

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

[Stewart Gordon]

A number of bugs on this theme have been raised.  I've just created a tracker: bug 1073827