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)
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)
11.77 KB,
application/octet-stream
|
Details | |
1.01 KB,
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
asa
:
approval-aviary+
|
Details | Diff | Splinter Review |
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....
Reporter | ||
Comment 1•20 years ago
|
||
Test extension for Thunderbird, which provides de-DE and en-US locales.
Assignee | ||
Comment 2•20 years ago
|
||
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
Assignee | ||
Comment 3•20 years ago
|
||
I am not feeling especially charitable towards the command line service these days.
Assignee | ||
Updated•20 years ago
|
Attachment #159171 -
Flags: superreview?(darin)
Attachment #159171 -
Flags: review?(darin)
Comment 4•20 years ago
|
||
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)
Assignee | ||
Comment 5•20 years ago
|
||
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
Assignee | ||
Updated•20 years ago
|
Attachment #159252 -
Flags: superreview?(darin)
Attachment #159252 -
Flags: review?(darin)
Comment 6•20 years ago
|
||
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?
Comment 7•20 years ago
|
||
maybe this instead? if (cmdLineArgs) cmdLineArgs->GetCmdLineValue(UILOCALE_CMD_LINE_ARG, getter_Copies(uiLocale)); if (uiLocale) { useLocalePref = PR_FALSE; mSelectedLocale = uiLocale; } else if (prefs) { ...
Updated•20 years ago
|
Attachment #159171 -
Flags: superreview?(darin)
Attachment #159171 -
Flags: review?(darin)
Assignee | ||
Updated•20 years ago
|
Attachment #159252 -
Flags: superreview?(darin)
Attachment #159252 -
Flags: review?(darin)
Assignee | ||
Comment 8•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #159252 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #159315 -
Flags: superreview?(darin)
Attachment #159315 -
Flags: review?(darin)
Comment 9•20 years ago
|
||
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+
Assignee | ||
Updated•20 years ago
|
Attachment #159315 -
Flags: approval-aviary?
Comment 10•20 years ago
|
||
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
Assignee | ||
Comment 11•20 years ago
|
||
I checked this in with bug 246014 when I merged that onto the trunk, so this patch is aviary-only now.
Comment 12•20 years ago
|
||
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+
Assignee | ||
Comment 13•20 years ago
|
||
Fixed on branch
Comment 14•20 years ago
|
||
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 → ---
Comment 15•20 years ago
|
||
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 ago → 20 years ago
Resolution: --- → FIXED
Comment 16•20 years ago
|
||
*** Bug 262732 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
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.
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•