Launchpad has imported 3 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=654099.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-05-02T14:10:57+00:00 Chris Coulson wrote: 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! Reply at: https://bugs.launchpad.net/firefox/+bug/643899/comments/17 ------------------------------------------------------------------------ On 2011-05-02T16:11:51+00:00 Smontagu wrote: Bug 647063 may be the same issue. Reply at: https://bugs.launchpad.net/firefox/+bug/643899/comments/18 ------------------------------------------------------------------------ On 2011-05-02T16:43:08+00:00 Philipp von Weitershausen wrote: (In reply to comment #1) > Bug 647063 may be the same issue. As may bug 616500. Reply at: https://bugs.launchpad.net/firefox/+bug/643899/comments/19 ** Changed in: firefox Status: Unknown => Confirmed ** Changed in: firefox Importance: Unknown => Medium ** Bug watch added: Mozilla Bugzilla #652934 https://bugzilla.mozilla.org/show_bug.cgi?id=652934 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/643899 Title: Firefox sending header "Accept-Language: chrome://global/locale/intl.properties" -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
