Closed Bug 1542566 Opened 2 years ago Closed 2 years ago

Fennec's Accept-Language header is inverted


(Firefox for Android Graveyard :: Locale switching and selection, defect, P1)

Firefox 66


(firefox-esr60 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 verified)

Firefox 68
Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- verified


(Reporter: sergio+it, Assigned: mbrubeck)



(Whiteboard: [bcs:p1])


(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

When I set system languages in Android settings to:

  1. English (United States)
  2. Русский (Россия)
    I got: Accept-Language: ru-RU,en-US;q=0.7,en;q=0.3

When I set system languages in Android settings to:

  1. Русский (Россия)
  2. English (United States)
    I got: Accept-Language: en-US,ru-RU,q=0.7,en;q=0.3

OP3T, LineageOS 16.0-20190405, Android 9

Expected results:

For 1.en Accept-Language should be en-US,en;q=0.7,ru-RU;q=0.3
For 2.en Accept-Language should be ru-RU,en-US;q=0.7,en;q=0.3


Thank you for reporting the issue.

I managed to reproduce the bug.

Device: Sony Xperia Z5, Android(7.0)
Build: Firefox Nightly 68.0a1 (2019-04-17) and Beta (67.0b11)

I will change the status of the bug to NEW.

With respect,
Diana Rus

Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → ARM


As an update for the issue, for a better understanding I will attach a screenshot with where the information can be found, in the image

This seems like a browser issue, NI-ing Chris to triage.

Thank you,
Diana Rus

Flags: needinfo?(cpeterson)

I can reproduce this bug intermittently. Sometimes Fennec's Accept-Language header picks up the new system language. Sometimes Fennec's Accept-Language header doesn't even pick up the new language when switching languages in Fennec's own Settings > General > Language. Sometimes when I tell Fennec to use the system language, it only picks up the first language.

I've been testing with, a site that echos back your HTTP request headers.

Also, Fennec has twice crashed immediately after switching the system language settings. I filed new bug 1546153.

Flags: needinfo?(cpeterson)
See Also: → 1310620
Whiteboard: [bcs:p1]
See Also: 13106201546153

Some investigation needed, starting from changing the Fennec setting onward and what that does (headers change, UI change, notify Gecko, system language changes, etc.).

See Also: → 1543823

We don't have accept-language design that when system locale is multiple. Actually, although locale system can support multiple system locale, we won't use it for accept-language well. If locale setting is matched OS, we have to respect it. (Chrome/Android already does)

Assignee: nobody → mbrubeck
Depends on: 1543823
See Also: 1543823
Summary: Accept-Language is inverted → Fennec's Accept-Language header is inverted

There are two places to control language settings for Firefox on Android: The Firefox settings (which are stored in pref "intl.locale.requested") and the Android OS settings.

The Firefox setting is meant to override the OS setting, so when they differ, Fennec places the Firefox setting first:

By default, the Firefox preference is unset or blank. Then, retrieving it from LocalService::ReadRequestedLocales is supposed to return the system setting (if using a multi-locale build where the preference is blank) or the app default (if using a single-locale build):

On Android, reading the system locale may fail during app startup, in which case we again fall back to the app default:

The fallback default is the update.locale file, which is "en-US" in our multi-locale packages.

For the purposes of setting this header, we want the app-level requestedLocale to override the OS locale only if it was explicitly set by the user. If it is a default/fallback value, then we should instead place the OS locale first.

I believe the correct way to do this is to check the "intl.locale.requested" pref directly so that we can have different behavior depending on whether it is set or unset.

(Additionally, we currently only look at the first locale from the OS settings. We should instead use the entire list.)

Pushed by
Put Android system locale before app default in Accept-Language. r=snorp

67=wontfix because it's too late to uplift for Fennec 67 Beta.

Interesting to see how the defaults and fallbacks should take precedence in different situations.

Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68


Checked with device Sony Xperia Z5, Android(7.0.0)on Fennec Nightly 68.0a1(2019-05-13)

While testing i have observed that for this first situation

  1. intl.locale.requested - unset(multi-local) and OS language changed
    OS Language used: Russian
    Expected: the OS language is applied for Fennec browser
    Screenshot attached - OS language different than browser

Is this the intended behavior?

  • intl.locale.requested - while having this changed will not have any value = so it does not take the OS language in backend.
  1. intl.locale.requested - set(single-local language)
    OS Language used: Russian
    Expected: the OS language is applied for Fennec browser
    Status: PASS

  2. intl.locale.requested - set as different than OS specifically
    Browser Language used: Russian
    Expected: the browser language is applied for pages
    Status: PASS - browser set to russian


Flags: needinfo?(mbrubeck)

Fennec has a default Accept-Language setting of "en-us,en" that is always included in the list, regardless of other settings. (This patch doesn't change that, though it does move the default so that it's always at the end of the list.)

We can file a separate bug if we decide to remove this default from the list completely, and send only the user-specified locales from the app and OS settings.

Flags: needinfo?(mbrubeck)


Verified as fixed as per Comment12

Thank you for responding.

The outcome is as you said, as per confirmation the ticket is fixed.


Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.