1893933 - intl.accept_languages picked from /etc/firefox/defaults/pref folder not working and causing UI problem

Status: UNCONFIRMED

(Core :: Preferences: Backend, defect, P3)

Description

[nogueira]

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

Steps to reproduce:

1. add the file /etc/firefox/defaults/pref/user-prefs.js
   with a line: pref("intl.accept_languages", "pt-pt,pt,en");
2. close firefox
3. remove the firefox profiles folder
4. start firefox

Actual results:

firefox is not sending the header "ACCEPT-LANGUAGE=pt-PT,pt;q=0.7,en;q=0.3"
and the Settings button for Choose your preferred languages for displaying pages does not work.

Expected results:

firefox should pick the intl.accept_languages pref from /etc/firefox/defaults/pref/user-prefs.js and use it as default to send the "ACCEPT-LANGUAGE=pt-PT,pt;q=0.7,en;q=0.3" header, and allow to change via Settings button.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Not sure which component is that but not widget/gtk.

Comment 3

[Marco Bonardo [:mak]]

Which Linux distribution are you using? Is it a flatpak or snap install?
Could you please attach a text log from about:support to this bug report?

Support for this file was apparently added in https://bugzilla.mozilla.org/show_bug.cgi?id=1170092, so moving this bug to Core:Preferences Backend

Comment 4

[nogueira]

Attachment: about_support.txt

Comment 5

[nogueira]

Attachment: video_of_the_bug_happening.mp4

Comment 6

[nogueira]

(In reply to Marco Bonardo [:mak] from comment #3)

Which Linux distribution are you using?
ArchLinux

Is it a flatpak or snap install?
native

Comment 7

[nogueira]

To rule out a possible problem with archlinux firefox install, I download firefox nightly firefox-128.0a1.en-US.linux-x86_64.tar.bz2 and the problem is present.

Comment 8

[Tom Ritter [:tjr]]

You have hit a truly amazing case of obscure conditions.

1. Because /etc/firefox/defaults/pref/user-prefs.js is a System File (as determined by us), the values in it are loaded in the pref Default branch, not the User branch.
2. intl.accept_languages is an unusual preference, it's not really a string, it a 'ComplexValue', specifically a localized string
3. Looking up a LocalizedString is handled here and if the preference is not locked (it's not) and it has no user value - it will look up the value of the pref from the properties file.
4. Recall above that your custom value is considered a Default Value not a User Value. So it does indeed get looked up from the properties file, an example of which would be here
5. Here's another crazy thing - while that's a fine value for a User value of this preference, it's not at all what a default value can be! - that needs to be a chrome:// url to a properties file to look up the value in!

You might be able to point your default preference value to a file:// URI (thankfully we have some restrictions built in...) of a custom properties file that looks like this with the values you want.

But... even if that works, I am not thrilled about the idea of creating a contract that this is a supported configuration. It is very obscure and makes a lot of implicit assumptions along the way.

Comment 9

[nogueira]

Thanks for such a detailed response, now it was easy to correct the intl.accept_languages default value.

Tested and working with:
pref("intl.accept_languages", "data:,intl.accept_languages=pt-pt,pt,en");

Comment 10

[nogueira]

The only weird thing, is that the about:config pref intl.accept_languages will display the value data:,intl.accept_languages=pt-pt,pt,en, that is only used as default value. Shouldn't the value be translated to a ComplexValue like pt-pt,pt,en?