Bug #643899 “Firefox sending header “Accept-Language: chrome://g...” : Bugs : firefox package : Ubuntu

Revision history for this message

Jason Gerard DeRose (jderose) wrote on 2010-09-20:

#1

Accept-Language.png Edit (67.0 KiB, image/png)
Dependencies.txt Edit (3.2 KiB, text/plain; charset="utf-8")
ExtensionSummary.txt Edit (736 bytes, text/plain; charset="utf-8")
KernLog.txt Edit (4.6 KiB, text/plain; charset="utf-8")
RelatedPackageVersions.txt Edit (155 bytes, text/plain; charset="utf-8")
profile_default_pluginreg.dat.txt Edit (2.8 KiB, text/plain; charset="utf-8")
profiles.ini.txt Edit (73 bytes, text/plain; charset="utf-8")

Revision history for this message

dazza5000 (darran-kelinske) wrote on 2010-09-20:

#2

Possibly related to this one in Windows:

https://bugzilla.mozilla.org/show_bug.cgi?id=438031

Montblanc (montblanc) on 2010-10-16

Changed in firefox (Ubuntu):
status:	New → Confirmed

Revision history for this message

wensveen (wensveen) wrote on 2010-11-08:

#3

https://bugzilla.mozilla.org/show_bug.cgi?id=438031 was recently, and in my opinion, wrongly closed.

Revision history for this message

wensveen (wensveen) wrote on 2010-11-08:

#4

See also: http://ubuntuforums.org/showthread.php?t=1536811

Revision history for this message

svecpetr (svecpetr-svecpetr) wrote on 2011-01-03:

#5

I'm affected by this bug too...

Revision history for this message

Sami Nieminen (sami-nieminen) wrote on 2011-03-24:

#6

After updating to Firefox 4 I experienced this bug also. In the preferences->languages there was value [chrome://global/locale/intl.properties] and links in www.google.com page were looking quite strange.

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2011-04-13:

#7

The Mozilla bug was rightly closed as the original reporter was trying to read the values incorrectly from their extension (using getCharPref rather than getComplexValue).

However, you seem to be having a problem where intl.accept_languages is set to the literal value "chrome://global/locale/intl.properties", which is an entirely separate issue. I'm not sure how your config ended up in that state. What extensions do you have installed?

Revision history for this message

Oliver Ewert (ollytheninja) wrote on 2011-04-17:

#8

I have the same issue:
HTTP_ACCEPT_LANGUAGE = chrome://global/locale/intl.properties
In firefox 4, ubuntu 10.10
still happens with all add-ons disabled

Revision history for this message

Oliver Ewert (ollytheninja) wrote on 2011-04-17:

#9

in firefox, go to about:config
type 'intl.accept_languages' into the filter
double click (or rightclick->modify) the intl.accept_languages entry
press ok and it will automatically convert chrome://global/locale/intl.properties into the actual language properties

Revision history for this message

Camille Appert (bibinou) wrote on 2011-04-21:

#10

Oliver, your workaround doesn't works with firefox 3.6.16+build1+nobinonly-0ubuntu0.10.10.1 on Maverick.

Revision history for this message

Oliver Ewert (ollytheninja) wrote on 2011-04-21:

#11

OK, sorry Camille,
I am on: firefox 4.0+nobinonly-0ubuntu1~mfs~maverick1
Can you still edit that entry?
In that case you could reset it manually by changing it to "en-us, en" or whichever language you prefer.

Sami Nieminen also noted that he was using Firefox 4, so it would be good to hear if my workaround worked for him.

Does everyone affexted by this bug have a version of chrome installed?
I am starting to think that this is an issue where chrome is adding the wrong values to the system settings...

Revision history for this message

Camille Appert (bibinou) wrote on 2011-04-22:

#12

Nothing to be sorry about :) I was just stating this for people still using 3.6.

By the way, are you using a PPA ? I can't find Firefox 4 in the repos.

Revision history for this message

Camille Appert (bibinou) wrote on 2011-04-22:

#13

List of Firefox extensions Edit (3.0 KiB, text/plain)

List of extensions, using https://addons.mozilla.org/en-us/firefox/addon/extension-list-dumper/

Revision history for this message

Oliver Ewert (ollytheninja) wrote on 2011-04-22:

#14

Yes I am, you need to add this ppa though
ppa:mozillateam/firefox-stable

that extension doesn't seem to work for me,
anything special that I need to do to make it work?

Revision history for this message

Camille Appert (bibinou) wrote on 2011-05-02:

#15

Hi Oliver,
On Firefox 4 there is a "Dump List" button on the top-right corner of about:addons (the Tools>Addons page).
Click it and select everything but Date and Description.
If you have any problems, let me know.

Revision history for this message

Sami Nieminen (sami-nieminen) wrote on 2011-05-02:

#16

> Does everyone affexted by this bug have a version of chrome installed?

I have Chrome installed so the problem may have something to do with it.

Revision history for this message

In Mozilla Bugzilla #654099, Chris Coulson (chrisccoulson) wrote on 2011-05-02:

#17

Download full text (7.5 KiB)

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 le...

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!

Revision history for this message

In Mozilla Bugzilla #654099, Smontagu (smontagu) wrote on 2011-05-02:

#18

Bug 647063 may be the same issue.

Revision history for this message

In Mozilla Bugzilla #654099, Philipp von Weitershausen (philikon) wrote on 2011-05-02:

#19

(In reply to comment #1)
> Bug 647063 may be the same issue.

As may bug 616500.

Chris Coulson (chrisccoulson) on 2011-05-02

Changed in firefox (Ubuntu):
status:	Confirmed → Triaged
importance:	Undecided → High

Bug Watch Updater (bug-watch-updater) on 2011-05-03

Changed in firefox:
importance:	Unknown → Medium
status:	Unknown → Confirmed

Chris Coulson (chrisccoulson) on 2011-05-03

affects:	firefox (Ubuntu) → ubuntu
affects:	Ubuntu Natty → firefox (Ubuntu Natty)
Changed in firefox (Ubuntu Natty):
assignee:	nobody → Chris Coulson (chrisccoulson)
importance:	Undecided → High
milestone:	none → natty-updates
status:	New → Triaged
Changed in firefox (Ubuntu Oneiric):
importance:	High → Medium
assignee:	nobody → Chris Coulson (chrisccoulson)

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2011-05-03:

#20

Chris, ack from me. I think regressing this is unfortunate, but that other bug is urgent. Lets make sure we open a new regression-updates tagged bug immediately upon upload so we don't forget.

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2011-05-03:

#21

It looks like the fix for bug 548866 contributes to this. As bug 548866 is mostly an edge case, we're going to regress that and back out the fix to fix this bug instead.

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2011-05-03:

#22

Oops, comments collided there ;)

Chris Coulson (chrisccoulson) on 2011-05-03

description:

updated

Revision history for this message

Martin Pitt (pitti) wrote on 2011-05-04: Please test proposed package

#23

Accepted firefox into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in firefox (Ubuntu Natty):
status:	Triaged → Fix Committed
tags:	added: verification-needed

Revision history for this message

Micah Gersten (micahg) wrote on 2011-05-10:

#24

Confirmed the version in proposed no longer experiences this change.

Chris Coulson (chrisccoulson) on 2011-05-10

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-05-17:

#25

This bug was fixed in the package firefox - 4.0.1+build1+nobinonly-0ubuntu0.11.04.2

---------------
firefox (4.0.1+build1+nobinonly-0ubuntu0.11.04.2) natty-proposed; urgency=low

  * Fix LP: #770719 - Dutch localization doesn't include spell-checker.
    Look in /usr/share/hunspell for the system dictionaries on maverick
    and later, rather than /usr/share/myspell/dicts. This got dropped
    somehow in natty
    - update debian/rules
    - update debian/firefox.links/in
  * Hopefully fix LP: #643899 - Firefox sending header "Accept-Language:
    chrome://global/locale/intl.properties" because the intl.accept_languages
    preference is messed up. Drop a patch which causes the preferences
    system to save a user preference when changing a preference value to equal
    the system default value (and revert to the original behaviour where the
    preference is just discarded). This should hopefully stop Firefox Sync
    from breaking localized preferences where they haven't been modified by
    the user, but does regress LP: #548866
    - update debian/patches/series
-- Chris Coulson <email address hidden> Tue, 03 May 2011 20:43:30 +0100

Changed in firefox (Ubuntu Natty):
status:	Fix Committed → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2011-05-17:

#26

Copied natty-proposed to oneiric as well.

Changed in firefox (Ubuntu Oneiric):
status:	Triaged → Fix Released

Ubuntu Foundations Team Bug Bot (crichton) on 2011-09-19

tags:

added: testcase

Revision history for this message

In Mozilla Bugzilla #654099, Rnewman-e (rnewman-e) wrote on 2011-12-10:

#27

*** Bug 580833 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #654099, Rnewman-e (rnewman-e) wrote on 2014-09-17:

#28

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.

Revision history for this message

In Mozilla Bugzilla #654099, Gavin Sharp (gavin-sharp) wrote on 2014-09-20:

#29

(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.

Revision history for this message

In Mozilla Bugzilla #654099, Mathieu Parent (math-parent) wrote on 2015-06-23:

#30

#438031 is also a dupe.

Bug Watch Updater (bug-watch-updater) on 2022-10-11

Changed in firefox:
importance:	Medium → Unknown

Ubuntu
firefox package

Firefox sending header "Accept-Language: chrome://global/locale/intl.properties"

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	Mozilla Firefox	Confirmed	Unknown	mozilla-bugs #654099
	firefox (Ubuntu)	Fix Released	Medium	Chris Coulson
Declined for Maverick by Chris Coulson
	Natty	Fix Released	High	Chris Coulson	Ubuntu natty-updates
	Oneiric	Fix Released	Medium	Chris Coulson

Ubuntufirefox package

Firefox sending header "Accept-Language: chrome://global/locale/intl.properties"

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
firefox package