Open
Bug 654099
Opened 13 years ago
Updated 2 years ago
intl.accept_languages is being set to non-localized value chrome://global/locale/intl.properties
Categories
(Firefox :: Sync, defect)
Firefox
Sync
Tracking
()
NEW
People
(Reporter: chrisccoulson, Unassigned)
References
Details
(Whiteboard: [sync:prefs][sync:rigor][sync:scale])
We're seeing quite a lot of users in Ubuntu reporting that intl.accept_languages is being modified to contain the non-localized value "chrome://global/locale/intl.properties" after upgrading to Firefox 4. A common side effect of this is that Google sites are setting users languages to Cherokee. intl.accept_languages should be a complex value, and the real value is shipped in the translation xpi's. I've also seen this once, and it happened almost immediately after manually forcing a sync of all my preferences. Once it happened, the broken value propagated to all of my profiles, although this might be coincidental and it's not easily reproducible. Here's a transcript of some conversation on #developers (and explains why I've reported a bug against sync): <chrisccoulson> are you seeing bugs from users where intl.accept_languages pref is getting set somehow to the literal value "chrome://global/locale/intl.properties" (rather than being localized)? <glandium> chrisccoulson: that probably means your language pack doesn't set it <chrisccoulson> glandium, hmmm, our language packs are setting it :/ (we just distribute the mozilla.org xpi's for language packs) i saw it too, after sync'ing my preferences but we are getting lots of people reporting this in ubuntu now after upgrading to firefox 4 <glandium> chrisccoulson: though, where do you see "chrome://global/locale/intl.properties" as the value ? <chrisccoulson> glandium, in about:config and in the accept header too <glandium> chrisccoulson: In about:config, that could be expected <chrisccoulson> it's causing google sites to mis-detect the language google is setting users language to cherokee ;) <glandium> chrisccoulson: the http code is supposed to use the proper API (GetComplexValue) <bz> chrisccoulson: I've seen one or two reports of that, yes <chrisccoulson> glandium, it is. but the preference is just getting messed up somewhere :/ and i'm really stuck for tracking it down <glandium> chrisccoulson: you should get these people to check that chrome://global/locale/intl.properties contains the right thing <bz> chrisccoulson: can you debug? chrisccoulson: I assume you can reproduce reliably, right? <chrisccoulson> glandium, it does. if the user resets the value in about:config, then it restores to the correct value and google starts working correctly <bz> hmm <chrisccoulson> bz - i can't reproduce reliably, which is why i'm having such a hard time debugging it :/ <bz> so about:config claims the value is modified? <glandium> ah, it's set to chrome://global/locale/intl.properties in the user profile ? <chrisccoulson> i only saw it once after synchronizing my preferences, and then the broken value propagated to all of my profiles <glandium> ewong|build: no idea. catlee would know <chrisccoulson> bz - yes, about:config claims that the value is modified <chrisccoulson> which makes me wonder if some extension is breaking it <bz> chrisccoulson: gimme a sec <bz> so.... <bz> intl.accept_languages is not supposed to be a localized pref, last I checked <smontagu> bz: I don't think that's correct <chrisccoulson> bz - hmm, but it's set to chrome://global/locale/intl.properties in greprefs.js <bz> at least over here the value about:config shows for me is just "en-us, en" <glandium> bz: what smontagu says <bz> but that may be because about:config does getComplexValue? * smontagu remembers it being localized for a logn time <glandium> bz: it didn't last time I checked but that could have changed * bz searches <bz> so yeah <glandium> it actually might be doing it now seeing how few chrome:// data i have in about:config <bz> about:config seems to load the locaized value er, localized value one sec 300 case gPrefBranch.PREF_STRING: 301 pref.valueCol = gPrefBranch.getComplexValue(prefName, nsISupportsString).data; 302 // Try in case it's a localized string (will throw an exception if not) 303 if (pref.lockCol == PREF_IS_DEFAULT_VALUE && 304 /^chrome:\/\/.+\/locale\/.+\.properties/.test(pref.valueCol)) 305 pref.valueCol = gPrefBranch.getComplexValue(prefName, nsIPrefLocalizedString).data; 306 break; sez about:config <-- otzi has quit (Quit: Changing server) <bz> (the source for it, that is) <Pike> "interesting" <glandium> that must be rather new <bz> which explains what I'm seeing but.... hg blame says hg@1 * bz won't bother looking at the cvs blame <bz> ok so HTTP does: <glandium> weird, i'm pretty sure about:config wasn't displaying the localized strings pretty recently <bz> 1074 nsCOMPtr<nsIPrefLocalizedString> pls; 1075 prefs->GetComplexValue(INTL_ACCEPT_LANGUAGES, 1076 NS_GET_IID(nsIPrefLocalizedString), 1077 getter_AddRefs(pls)); <Pike> glandium: I don't remember it doing anything but that, really <bz> and then nsPrefBranch::GetComplexValue does.... 231 PRBool bNeedDefault = PR_FALSE; ... 237 if (!PREF_HasUserPref(pref) && !PREF_PrefIsLocked(pref)) { 238 bNeedDefault = PR_TRUE; 239 } 242 // if we need to fetch the default value, do that instead, otherwise use the 243 // value we pulled in at the top of this function 244 if (bNeedDefault) { 246 rv = GetDefaultFromPropertiesFile(pref, getter_Copies(utf16String)); <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86.1 [SeaMonkey 2.0.14/20110420230004]) <bz> 250 } else { 251 rv = GetCharPref(aPrefName, getter_Copies(utf8String)); <glandium> Pike: yeah, i must have smoked something, because i checked in 3.6 and 3.5, and they did <bz> alright So if you have a user-set value for a localized-string pref, it just doesn't work so if you have someone going around setting prefs to their current value, say, that someone will break localized string prefs nice <glandium> bz: yeah, that's a kind of known issue, though i don't know if it's intentional * bz neither <bz> chrisccoulson: I bet you're right about some extension screwing this up * smontagu is puzzled again <highlight_me> yeah, it's always an extension that screws things up :P <chrisccoulson> bz - does http://mxr.mozilla.org/mozilla-central/source/services/sync/modules/ext/Preferences.js#157 work for localized prefs? <smontagu> I have used a user-set value for intl.accept_languages since like forever <bz> yes, but did you user-set it to chrome://something.properties ? or did you set it to the actual string you wanted to be used? <chrisccoulson> shouldn't it be nsIPrefLocalizedString? <smontagu> to the string I wanted to use <bz> right the prefs code uses the string as-is if it's user-set and if not, it looks for the .properties file and gets it from there <chrisccoulson> (note, i only saw this mess up after forcing a sync, and intl.accept_languages is a pref that is synchronized) <bz> so if you user-set it to the chrome://something.properties thing, you lose <bz> chrisccoulson: oh, _interesting_ chrisccoulson: I wonder whether sync could be clobbering it! <bz> https://bugzilla.mozilla.org/show_bug.cgi?id=652934 fwiw <chrisccoulson> bz - that's what i'm starting to think bz - thanks <bz> not sure that's the same as your issue since in that case it has the en-ie as well <bz> chrisccoulson: we should probably just get a clean Sync bug filed chrisccoulson: esp. if you can confirm that Sync causes this <chrisccoulson> bz - i only saw it happen once, so it could be purely coincidental <bz> Still worth checking, imho it's got method and opportunity! and motive <chrisccoulson> bz - want me to file that? <-- highlight_me has quit (Quit: Exit, Close) <bz> so the only question is whether it's the criminal please!
Comment 1•13 years ago
|
||
Bug 647063 may be the same issue.
Comment 2•13 years ago
|
||
(In reply to comment #1) > Bug 647063 may be the same issue. As may bug 616500.
See Also: → https://launchpad.net/bugs/643899
Updated•12 years ago
|
OS: Linux → All
Whiteboard: [sync:prefs]
Updated•12 years ago
|
Whiteboard: [sync:prefs] → [sync:prefs][sync:rigor][sync:scale]
Comment 4•10 years ago
|
||
I think the root cause for this is: toolkit/modules/Preferences.jsm: _get: function(prefName, defaultValue) { switch (this._prefSvc.getPrefType(prefName)) { case Ci.nsIPrefBranch.PREF_STRING: return this._prefSvc.getComplexValue(prefName, Ci.nsISupportsString).data; In the case of localizable prefs, that should be gCV(prefName, Ci.nsIPrefLocalizedString) to get the right value. I think the code as written will grab intl.properties instead of actually reading the real value. But even that might be broken -- when syncing between two Firefoxes with different locales. I suspect there needs to be more sophisticated handling here altogether.
Comment 5•10 years ago
|
||
(In reply to Richard Newman [:rnewman] from comment #4) > I think the code as written will grab intl.properties instead of actually reading > the real value. It will indeed, but that's not necessarily a problem if it sets the pref the same way (setComplexValue(..., nsISupportsString)), as long as that URI resolves to something that exists and contains a value for that pref in both Firefoxes. It's hard to think of cases where that wouldn't hold, but that probably explains why this isn't affecting most Sync users.
Comment 6•9 years ago
|
||
#438031 is also a dupe.
Assignee | ||
Updated•6 years ago
|
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•