Closed Bug 258725 Opened 20 years ago Closed 20 years ago

Incorrect chrome registration of multilingual extensions (including multiple locales)

Categories

(Toolkit :: Startup and Profile System, defect)

1.7 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.7.5

People

(Reporter: Thunderbird_Mail_DE, Assigned: benjamin)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Thunderbird 0.8 branch 20040905

If you're installing an extension into Thunderbird (or Firefox), which provides
multiple locales (e.g. en-US and de-DE), the application should register the the
correct locale for the extension. The correct locale should be the actual used
locale by the core application.
Only if the extension does NOT provide the applications actual/"core" locale, we
should fall back to another provided locale in the install.rdf.

Reproducible: Always
Steps to Reproduce:
1. Use an en-US Thunderbird
2. Install the attacht multilingual extension (en-US and de-DE)
3. restart Thunderbird and open the extension manager
4. open the extensions options dialog

Actual Results:  
You'll get an German (de-DE) options dialog instead of an (en-US) English
dialog. The extension is registered with the (false) de-DE locale.

Expected Results:  
You should get registered an Englisch (en-US) locale for the extension, because
of the applications core locale (en-US).

It seems, the extension manager is registering the first locale out of the
install.rdf. The applications actual/"core" locale is not used to identify the
correct locale for the extension.

IMHO this is a pain for users, who are using extensions. And we are propagating
the extension feature all over the world....
Test extension for Thunderbird, which provides de-DE and en-US locales.
Mine. There are several manifestations of this bug going around, somehow the
"default locale" clause of provider selection is missing some important bits in
the chrome registry (although we're still better off than no locale at all being
selected, though not by much).
Assignee: mscott → bsmedberg
Status: UNCONFIRMED → NEW
Component: General → Startup and Profile System
Ever confirmed: true
Product: Thunderbird → Firefox
Target Milestone: --- → Firefox1.0
Version: unspecified → 1.0 Branch
I am not feeling especially charitable towards the command line service these
days.
Attachment #159171 - Flags: superreview?(darin)
Attachment #159171 - Flags: review?(darin)
Comment on attachment 159171 [details] [diff] [review]
work around the fucking command line service

are you sure this does the right thing when |uiLocale| is not null? 
getter_Copies does not actually assign a value to uiLocale until the
getter_Copies destructor runs.	(this was an unfortunate result of the string
rewrite from earlier this year -- see bug 234908)
Attached patch Fix scoping (obsolete) — Splinter Review
Yeah, we shouldn't play ping-pong with regressions. I decided to ignore the rv
from GetCmdLineValue since it never returns a meaningful failure code.
Attachment #159171 - Attachment is obsolete: true
Attachment #159252 - Flags: superreview?(darin)
Attachment #159252 - Flags: review?(darin)
Comment on attachment 159252 [details] [diff] [review]
Fix scoping

but doesn't this change the logic?  before: if cmdLineArgs and !uiLocale, we'd
try the prefs.	now, if cmdLineArgs and !uiLocale, we do nothing.  is that what
we want?
maybe this instead?

  if (cmdLineArgs)
    cmdLineArgs->GetCmdLineValue(UILOCALE_CMD_LINE_ARG, getter_Copies(uiLocale));
  if (uiLocale) {
    useLocalePref = PR_FALSE;
    mSelectedLocale = uiLocale;
  }
  else if (prefs) {
    ...
Attachment #159171 - Flags: superreview?(darin)
Attachment #159171 - Flags: review?(darin)
Attachment #159252 - Flags: superreview?(darin)
Attachment #159252 - Flags: review?(darin)
Attachment #159252 - Attachment is obsolete: true
Attachment #159315 - Flags: superreview?(darin)
Attachment #159315 - Flags: review?(darin)
Blocks: 259167
Comment on attachment 159315 [details] [diff] [review]
Scope and ifs, third time's the charm?

r+sr=darin
Attachment #159315 - Flags: superreview?(darin)
Attachment #159315 - Flags: superreview+
Attachment #159315 - Flags: review?(darin)
Attachment #159315 - Flags: review+
Attachment #159315 - Flags: approval-aviary?
I found the original reporter's behaviour in the 0.8 milestone of
Thunderbird when I installed
http://downloads.mozdev.org/mnenhy/mnenhy-0.6.0.104.xpi;
Thunderbird in English, Mnenhy in German. Thinking that it might
be related to the lack of a locale in Thunderbird's user agent
string, I installed the Thunderbird 20040917 nightly, but still
had the same problem. Somewhere along the way, I also installed
MessageID-Finder 1.9.7, which was also in German. Changing the
lines in:

C:\WINDOWS\Application Data\Thunderbird\Profiles\xxxxxxxx.default\chrome\chrome.rdf

from:

  <RDF:Seq RDF:about="urn:mozilla:locale:root">
    <RDF:li RDF:resource="urn:mozilla:locale:de-AT"/>
    <RDF:li RDF:resource="urn:mozilla:locale:de-DE"/>
    <RDF:li RDF:resource="urn:mozilla:locale:en-GB"/>
    <RDF:li RDF:resource="urn:mozilla:locale:en-US"/>
    <RDF:li RDF:resource="urn:mozilla:locale:fr-FR"/>
    <RDF:li RDF:resource="urn:mozilla:locale:it-IT"/>
    <RDF:li RDF:resource="urn:mozilla:locale:pl-PL"/>
  </RDF:Seq>

to:

  <RDF:Seq RDF:about="urn:mozilla:locale:root">
    <RDF:li RDF:resource="urn:mozilla:locale:en-US"/>
    <RDF:li RDF:resource="urn:mozilla:locale:de-AT"/>
    <RDF:li RDF:resource="urn:mozilla:locale:de-DE"/>
    <RDF:li RDF:resource="urn:mozilla:locale:en-GB"/>
    <RDF:li RDF:resource="urn:mozilla:locale:fr-FR"/>
    <RDF:li RDF:resource="urn:mozilla:locale:it-IT"/>
    <RDF:li RDF:resource="urn:mozilla:locale:pl-PL"/>
  </RDF:Seq>

results in both extensions being in English.

Note that I have the same version of the Mnenhy extension
installed in Firefox, but never had the problem there.

This is with:

Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10
Mnenhy/0.6.0.104

and:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040917 Thunderbird/0.8
Mnenhy/0.6.0.104
I checked this in with bug 246014 when I merged that onto the trunk, so this
patch is aviary-only now.
Comment on attachment 159315 [details] [diff] [review]
Scope and ifs, third time's the charm?

a=asa for aviary checkin.
Attachment #159315 - Flags: approval-aviary? → approval-aviary+
Fixed on branch
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Unless I badly misunderstood something, the patch does not solve this issue. I
just tried the newest nightly build, which according to Burning Edge has this fix:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040922
Firefox/0.10

However, when installing Mouse Gestures 0.9.20040902 (an older version where
de-AT is listed before en-US in install.rdf, get it from update.mozilla.org via
"other releases" page) into a fresh profile, Firefox still selects de-AT for
MozGest. You can see this because MozGest asks "English texts are available, use
them?" (Clicking yes won't help, as selectLocaleForPackage was removed. Clicking
no and it won't ask again, but stay on de-AT.) Also, if you do some gesture with
RMB, you'll see "Mausgeste: ..." in the status bar, which is from the de-AT locale.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry, false alarm! Today's lesson is: *Never* assume that the Burning Edge is
accurate! The firefox 20040922 nightly does *not* have the fix. However, the
tinderbox builds at
ftp://ftp-new.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/sweetlou/
have it, and Firefox indeed selects en-US correctly for the MozGest build
mentioned above.

Resolving again.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
*** Bug 262732 has been marked as a duplicate of this bug. ***
Is this fixed in 1.0? In the latest version of Forecastfox, there have been a
lot of reports about it choosing seemingly random locales, when it should choose
en-US.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.