Hi, when setting intl.locale.matchOS to true in about:config, it is not taken into account. In order for locale to match os one (instead of firefox one), I need to set intl.locale.matchOS in firefox global preferences file (greprefs/all.js). The reason is: matchOS is looked for in nsChromeRegistry::Init http://localhost/lxr/source/chrome/src/nsChromeRegistry.cpp#548 that function in called in ScopedXPCOMStartup::SetWindowCreator when creating cr http://localhost/lxr/source/toolkit/xre/nsAppRunner.cpp#1080 and that code is called in ProfileLockedDialog before user prefs are loaded. It would be nice to be load user preferences before intl.locale.matchOS is checked so we could overrid that pref in profile instead of modifying a file from firefox.

Not sure if Preferences is the right component, IMHO, this is more of xpcom/xulrunner/toolkit startup kind a thing. Benjamin?

(I couldn't find a chrome component in toolkit or core products, so I'll leave it to preferences, though it definitely isn't the right component) This patch allows the matchOS preference to be set in user prefs to a value different from the one in gre preferences. If set to true, it uses the OS locale, if set to false, it resets the locale with the general.useragent.locale preference. It also allows general.useragent.locale, if set in user preferences, to override the OS locale.

Is this a DUPE of bug 519468?

Oh, yes it is. Though the new behaviour is not exactly the same as mine, but it is mostly fine. Let's just hope that Quick Select Locale and similar extensions will also set matchOS to false.

Or, if you think it would be worth to have the current Quick Locale Switcher to work as expected when matchOS is set to true at GRE level (which i think most linux distro do), I can file a new bug to have general.useragent.locale override matchOS when set.

Yeah, sounds like a good follow-up bug. Resolving DUPE.