438031 - intl.accept_languages reports chrome://global/locale/intl.properties

Status: RESOLVED INVALID

(Firefox :: Settings UI, defect)

Description

[Rolf Bode-Meyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre

In an extension I'm trying to retrieve the languages the user has chosen. So I have a look at the pref intl.accept_languages via getCharPref() from my JS code.

If the pref is user edited (directly or the UI), the returned value is ok (e.g. "en-us,en"), but after resetting the pref via about:config, the value I get for the pref is "chrome://global/locale/intl.properties".

Reproducible: Always

Comment 1

[Rolf Bode-Meyer]

Ok, this also happens with other prefs like font.language.group and thus I somehow suspect it's a feature. I just can't see how this should help anyone.

At least the HTTP Accept-Language header contains the right values even if the pref is on default.

Comment 2

[Tyler Downer [He/Him]]

This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.

Comment 3

[Matthijs Wensveen]

I hit this report via https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/643899, and can confirm this is an issue.

This is possibly related to Firefox Sync and Xmarks (possibly uninstalling Xmarks), see: http://webapps.stackexchange.com/questions/5042/google-what-language-is-chr-and-why-is-my-homepage-set-there.
Some other info: http://ubuntuforums.org/showthread.php?p=10025907

I can't change the status or anything, and I'm not even sure this is a firefox bug per se.

Comment 4

[Axel Hecht [:Pike]]

Works as designed. You should use getComplexValue, with an nsIPrefLocalizedString.

https://developer.mozilla.org/en/Code_snippets/Preferences#nsIPrefLocalizedString has a code snippet.

Comment 5

[Matthijs Wensveen]

Should the preference UI also report "[chrome://global/locale/intl.properties]"? See attached screenshot. At the very least this is an issue with that dialog.

According to http://whatsmyuseragent.com/ this is also sent as a HTTP_ACCEPT_LANGUAGE header, which causes the problem with google searches.

Could it be that the preference is somehow mangled by firefox sync?

BTW. Using Firefox 3.6.10.
BTW2. I don't think this should be RESOLVED INVALID. Looking at the forums, this causes real problems for people...

Comment 6

[Matthijs Wensveen]

Attachment: Screenshot showing the preference UI with an 'invalid' value.

Comment 7

[Axel Hecht [:Pike]]

I don't know how you guys broke that, but it's working on our builds for ages. Not sure if about:support would show something for intl.accept_languages

The bug report is about using getCharPref resulting in a chrome url, and that's what it's supposed to do.

Comment 8

[Shaya Potter]

intereesting tidbit I've been suffering from this for a while of the invalid chrome value, though didn't know it.

for a long time I have not been able to connect to newegg from my normal firefox profile, but it would work from clean profiles and chrome on same box.

in wireshark, I'd just see time outs and tcp retries.

Today I decided to compare the two closely, and noticed the differences in the accept language header.  Fixed up the preference and everything works again.

So it would seem that some firewalls reject packets with invalid accept language data.