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!
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)? //global/ locale/ intl.properties " as the value ? //global/ locale/ intl.properties contains the right thing //global/ locale/ intl.properties in the user profile ? languages is not supposed to be a localized pref, last I checked //global/ locale/ intl.properties in greprefs.js PREF_STRING: getComplexValue (prefName, nsISupportsStri ng).data; DEFAULT_ VALUE && \/\/.+\ /locale\ /.+\.properties /.test( pref.valueCol) ) getComplexValue (prefName, nsIPrefLocalize dString) .data; nsIPrefLocalize dString> pls; GetComplexValue (INTL_ACCEPT_ LANGUAGES, IID(nsIPrefLoca lizedString) , AddRefs( pls)); :GetComplexValu e does.... HasUserPref( pref) && !PREF_PrefIsLoc ked(pref) ) { ropertiesFile( pref, getter_ Copies( utf16String) ); 20110420230004] ) aPrefName, getter_ Copies( utf8String) ); mxr.mozilla. org/mozilla- central/ source/ services/ sync/modules/ ext/Preferences .js#157 work for localized prefs? languages since like forever //something. properties ? dString? languages is a pref that is synchronized) //something. properties thing, you lose /bugzilla. mozilla. org/show_ bug.cgi? id=652934
<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:
<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:
<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:
<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_
<smontagu> bz: I don't think that's correct
<chrisccoulson> bz - hmm, but it's set to chrome:
<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.
301 pref.valueCol = gPrefBranch.
302 // Try in case it's a localized string (will throw an exception if not)
303 if (pref.lockCol == PREF_IS_
304 /^chrome:
305 pref.valueCol = gPrefBranch.
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<
1075 prefs->
1076 NS_GET_
1077 getter_
<Pike> glandium: I don't remember it doing anything but that, really
<bz> and then nsPrefBranch:
231 PRBool bNeedDefault = PR_FALSE;
...
237 if (!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 = GetDefaultFromP
<-- Mnyromyr has quit (Quit: ChatZilla 0.9.86.1 [SeaMonkey 2.0.14/
<bz> 250 } else {
251 rv = GetCharPref(
<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://
<smontagu> I have used a user-set value for intl.accept_
<bz> yes, but did you user-set it to chrome:
or did you set it to the actual string you wanted to be used?
<chrisccoulson> shouldn't it be nsIPrefLocalize
<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_
<bz> so if you user-set it to the chrome:
<bz> chrisccoulson: oh, _interesting_
chrisccoulson: I wonder whether sync could be clobbering it!
<bz> https:/
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!