Dictionary keeps switching to en-US despite being set otherwise

RESOLVED FIXED in mozilla9

Status

()

Core
Spelling checker
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: Paul [pwd], Assigned: arno renevier)

Tracking

({regression})

Trunk
mozilla9
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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

6 years ago
OS: Windows 7 → All
Hardware: x86 → All

Updated

6 years ago
Blocks: 338427
Component: General → Spelling checker
Keywords: regression
Product: Firefox → Core
QA Contact: general → spelling-checker

Comment 1

6 years ago
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

6 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

6 years ago
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
Attachment #556487 - Flags: review?(ehsan)

Updated

6 years ago
Assignee: nobody → arno
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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

6 years ago
Created attachment 557474 [details] [diff] [review]
updated patch

updated patch to change variable name
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
Attachment #556487 - Attachment is obsolete: true
In my queue :-)
Keywords: checkin-needed
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
Target Milestone: --- → mozilla9
Backed out of mozilla-inbound because of mochitest-oth oranges like this:

https://tbpl.mozilla.org/php/getParsedLog.php?id=6237599
Target Milestone: mozilla9 → ---
Strange, didn't show on the try run (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=984e63e9170b), presume intermittent.
(Assignee)

Comment 11

6 years ago
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
Attachment #557474 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/d09cbf88c277
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla9
http://hg.mozilla.org/mozilla-central/rev/d09cbf88c277
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 14

6 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

5 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.
(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!
Blocks: 717433
(Clearing to stop this request showing up on the 'My Requests' page)
Flags: in-testsuite?
(Reporter)

Updated

4 years ago
Blocks: 728069

Comment 22

4 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

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

Updated

2 years ago
See Also: → bug 1073827
You need to log in before you can comment on or make changes to this bug.