Last Comment Bug 682564 - Dictionary keeps switching to en-US despite being set otherwise
: Dictionary keeps switching to en-US despite being set otherwise
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Spelling checker (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla9
Assigned To: arno renevier
:
Mentors:
Depends on:
Blocks: 338427 717433 728069
  Show dependency treegraph
 
Reported: 2011-08-27 08:32 PDT by Paul [pwd]
Modified: 2015-09-01 13:02 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch proposal (3.48 KB, patch)
2011-08-29 00:51 PDT, arno renevier
ehsan: review+
Details | Diff | Review
updated patch (3.45 KB, patch)
2011-09-01 06:04 PDT, arno renevier
no flags Details | Diff | Review
patch fixing wrong variable (3.45 KB, patch)
2011-09-02 06:57 PDT, arno renevier
no flags Details | Diff | Review

Description Paul [pwd] 2011-08-27 08:32:46 PDT
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**** 2011-08-27 16:35:49 PDT
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 2011-08-29 00:50:10 PDT
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 2011-08-29 00:51:40 PDT
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 4 :Ehsan Akhgari (busy, don't ask for review please) 2011-08-31 14:44:32 PDT
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 2011-09-01 06:04:17 PDT
Created attachment 557474 [details] [diff] [review]
updated patch

updated patch to change variable name
Comment 6 Ed Morley [:emorley] 2011-09-01 09:09:35 PDT
In my queue :-)
Comment 7 Ed Morley [:emorley] 2011-09-01 09:33:27 PDT
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 9 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-01 18:06:18 PDT
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] 2011-09-02 01:54:17 PDT
Strange, didn't show on the try run (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=984e63e9170b), presume intermittent.
Comment 11 arno renevier 2011-09-02 06:57:27 PDT
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
Comment 13 Ed Morley [:emorley] 2011-09-04 16:44:11 PDT
http://hg.mozilla.org/mozilla-central/rev/d09cbf88c277
Comment 14 Mozilla RelEng Bot 2011-09-06 15:30:49 PDT
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
Comment 15 Paul [pwd] 2012-01-11 08:13:00 PST
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 (busy, don't ask for review please) 2012-01-11 12:37:18 PST
(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] 2012-01-11 12:40:57 PST
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 (busy, don't ask for review please) 2012-01-11 12:42:25 PST
Do you have steps to reproduce?
Comment 19 Ed Morley [:emorley] 2012-01-11 12:53:20 PST
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 (busy, don't ask for review please) 2012-01-11 13:21:25 PST
(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] 2012-09-14 03:07:40 PDT
(Clearing to stop this request showing up on the 'My Requests' page)
Comment 22 ronfrancis 2013-10-27 00:25:35 PDT
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 2014-09-27 11:06:32 PDT
A number of bugs on this theme have been raised.  I've just created a tracker: bug 1073827

Note You need to log in before you can comment on or make changes to this bug.