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!