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

Bug #643899 reported by Jason Gerard DeRose on 2010-09-20
This bug affects 30 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox (Ubuntu)
Chris Coulson
Declined for Maverick by Chris Coulson
Chris Coulson
Chris Coulson

Bug Description

Binary package hint: firefox

Upgraded from Lucid to Maverick a bit ago, and now a recent update has caused Firefox to start sending the wrong Accept-Language header. Couldn't find an existing bug report, but I see it was discussed on the forums:


As the original bug isn't easily reproducible, it isn't possible to verify with 100% confidence that the update fixes the actual bug. However, we can test with 100% confidence the bug which we *think* is causing this bug here.

To prepare for this:

1) Install the extension-developer addon from
2) Open about:config, and ensure that "intl.accept_languages" does not have a user value (it will have "default" in the status column and be set to a list of language codes, such as "en-gb, en").

To test:
1) Open a JS shell (Tools -> Extension Developer -> Javascript Shell).
2) In the shell, click on the "enumerateWindows()" link
3) In the list of windows, click on "chrome://browser/content/browser.xul". This puts us in main window context
4) Enter the following:

gPrefService.setComplexValue("intl.accept_languages", Ci.nsISupportsString, string);

5) Check "intl.accept_languages" again in about:config

Expected result:
- With Firefox 4.0.1+build1+nobinonly-0ubuntu0.11.04.1, intl.accept_languages will contain the value "chrome://global/locale/", and the status column will say "user set"
- With Firefox 4.0.1+build1+nobinonly-0ubuntu0.11.04.2, intl.accept_languages should remain unchanged, and still display the default setting for your locale

ProblemType: BugDistroRelease: Ubuntu 10.10
Package: firefox 3.6.10+build1+nobinonly-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
CheckboxSubmission: fdbdfcded0c0bb479a6b52e9ec5af131
CheckboxSystem: edda5d4f616ca792bf437989cb597002
Date: Mon Sep 20 15:11:14 2010
EcryptfsInUse: Yes
 firefox 3.6.10+build1+nobinonly-0ubuntu2
 firefox-gnome-support 3.6.10+build1+nobinonly-0ubuntu2
 firefox-branding 3.6.10+build1+nobinonly-0ubuntu2
 abroswer N/A
 abrowser-branding N/AInstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
 PATH=(custom, user)
 SHELL=/bin/bashSourcePackage: firefox

Jason Gerard DeRose (jderose) wrote :
dazza5000 (darran-kelinske) wrote :

Possibly related to this one in Windows:

Montblanc (montblanc) on 2010-10-16
Changed in firefox (Ubuntu):
status: New → Confirmed
wensveen (wensveen) wrote : was recently, and in my opinion, wrongly closed.

svecpetr (svecpetr-svecpetr) wrote :

I'm affected by this bug too...

Sami Nieminen (sami-nieminen) wrote :

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

Chris Coulson (chrisccoulson) wrote :

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/", which is an entirely separate issue. I'm not sure how your config ended up in that state. What extensions do you have installed?

Oliver Ewert (ollytheninja) wrote :

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

Oliver Ewert (ollytheninja) wrote :

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/ into the actual language properties

Camille Appert (bibinou) wrote :

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

Oliver Ewert (ollytheninja) wrote :

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

Camille Appert (bibinou) wrote :

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.

Oliver Ewert (ollytheninja) wrote :

Yes I am, you need to add this ppa though

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

Camille Appert (bibinou) wrote :

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.

Sami Nieminen (sami-nieminen) wrote :

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

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/" 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/" (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 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/" 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/ 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/ 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/ in greprefs.js
<bz> at le...


Bug 647063 may be the same issue.

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

As may bug 616500.

Changed in firefox (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
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)
Clint Byrum (clint-fewbar) wrote :

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.

Chris Coulson (chrisccoulson) wrote :

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.

Chris Coulson (chrisccoulson) wrote :

Oops, comments collided there ;)

description: updated

Accepted firefox into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See 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
Micah Gersten (micahg) wrote :

Confirmed the version in proposed no longer experiences this change.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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/" 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
Martin Pitt (pitti) wrote :

Copied natty-proposed to oneiric as well.

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

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

I think the root cause for this is:


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

(In reply to Richard Newman [:rnewman] from comment #4)
> I think the code as written will grab 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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.