[OTHER] Reconsider `extensions.installDistroAddons->false`

degausser commented

2026-06-07 00:02:50 +02:00

Please explain your inquiry.

the pref also affects firefox language packs, shipped by distributions (e.g. debian); with falsy default, the firefox ui is en-us only on a non-english system (despite firefox{,-esr}-l10n-$LANG packages installed), unless the user downloads a language pack from mozilla somewhere to ~/.config/mozilla manually, from the menu in about:preferences#general. extensions.*Scopes are fine to stay as they currently are.

### Please explain your inquiry. the pref also affects firefox **language packs**, shipped by distributions (e.g. debian); with falsy default, the firefox ui is en-us only on a non-english system (despite `firefox{,-esr}-l10n-$LANG` packages installed), unless the user downloads a language pack from mozilla somewhere to `~/.config/mozilla` manually, from the menu in `about:preferences#general`. `extensions.*Scopes` are fine to stay as they currently are.

degausser added the

other

label

2026-06-07 00:02:50 +02:00

celenity commented

2026-06-07 02:30:27 +02:00

Owner

@degausser Thank you for filing this and raising this point!

This does sound problematic. I'd really rather not set extensions.installDistroAddons back to true if possible, due to the privacy and security concerns of allowing add-ons to be installed from external/system locations - IMO the installation of extensions should be left entirely in control of/up to the user. If it were possible to only allow language packs, I'd probably be okay with that, but AFAIK that unfortunately isn't possible.

(As an aside, I wonder why Mozilla (and package managers) aren't just doing multi-locale builds for Desktop? That's what ex. LibreWolf does, and it's what Mozilla does for Android builds as well).

But I think it is important that we find a solution for this.

One potential idea I have is that we could consider just installing all of the official language packs out of the box? This would effectively convert any build to a multi-locale one. Downside is obviously we'd be adding extra "bloat" (though the sizes do seem small, ex. around 200-300 KB each), but I think that would solve this issue, and it could also have other benefits as well (Ex. It'd prevent users who download the language pack for their locale from sticking out to Mozilla. It'd also ensure we're only downloading/using language packs directly from Mozilla, instead of those from a third-party. We also wouldn't have to worry about maintaining/manually updating the language packs, since we could just point them to always download the latest from AMO).

@degausser Please let me know what you think, and if you have any other ideas for a possible solution.

@degausser Thank you for filing this and raising this point! This does sound problematic. I'd really rather not set `extensions.installDistroAddons` back to `true` if possible, due to the privacy and security concerns of allowing add-ons to be installed from external/system locations - IMO the installation of extensions should be left entirely in control of/up to the user. If it were possible to *only* allow language packs, I'd probably be okay with that, but AFAIK that unfortunately isn't possible. *(As an aside, I wonder why Mozilla (and package managers) aren't just doing multi-locale builds for Desktop? That's what ex. LibreWolf does, and it's what Mozilla does for Android builds as well)*. But I think it is important that we find a solution for this. One potential idea I have is that we could consider just installing [all of the official language packs](https://addons.mozilla.org/firefox/language-tools/) out of the box? This would effectively convert any build to a multi-locale one. Downside is obviously we'd be adding extra "bloat" *(though the sizes do seem small, ex. around 200-300 KB each)*, but I think that would solve this issue, and it could also have other benefits as well *(Ex. It'd prevent users who download the language pack for their locale from sticking out to Mozilla. It'd also ensure we're only downloading/using language packs directly from Mozilla, instead of those from a third-party. We also wouldn't have to worry about maintaining/manually updating the language packs, since we could just point them to always download the latest from AMO)*. @degausser Please let me know what you think, and if you have any other ideas for a possible solution.

degausser commented

2026-06-07 03:42:14 +02:00

Author

@celenity the pref could be at least tagged as [NO-LINUX] - langpacks are distributed differently on other platforms ( == nothing of value is lost in keeping it), but afaik on linux (debian+derivatives, fedora, arch), the path for the sideloaded extensions is only in install dir, so /usr/lib{,64}/firefox/browser/extensions, which needs the same permissions to modify (root) as installing the browser. the user is in control here, via their package manager. in regards to some adversarial relationship with one's own distro packages - the firefox binary itself is sourced from there (also phoenix btw, on debian).
i would strongly advise against force-downloading & installing all langpacks on first run for everyone.
ironically, the inclusion of the pref (as false) would be fairly valuable for librewolf (since as you said, they bundle all langpacks - not as xpis though, in omni.ja), but that's not really relevant here.

@celenity the pref could be at least tagged as `[NO-LINUX]` - langpacks are distributed differently on other platforms ( == nothing of value is lost in keeping it), but afaik on linux (debian+derivatives, fedora, arch), the path for the sideloaded extensions is only in install dir, so `/usr/lib{,64}/firefox/browser/extensions`, which needs the same permissions to modify (root) as installing the browser. the user is in control here, via their package manager. in regards to some adversarial relationship with one's own distro packages - the `firefox` binary itself is sourced from there (also `phoenix` btw, on debian). i would strongly advise against force-downloading & installing all langpacks on first run for everyone. ironically, the inclusion of the pref (as `false`) would be fairly valuable for librewolf (since as you said, they bundle all langpacks - not as `xpi`s though, in `omni.ja`), but that's not really relevant here.

celenity commented

2026-06-07 07:45:15 +02:00

Owner

@degausser wrote in #309 (comment):

the user is in control here, via their package manager.

They might be in control there, but I don't think that's something we can/should safely assume or guarantee.

For example, if I install an add-on from https://addons.mozilla.org within the browser, obviously I'm making the conscious, direct, informed decision to install that add-on.

Even if I copy an extension to my profile directory from outside the browser, Firefox displays a warning and doesn't enable the extension by default, which allows me as a user to make the conscious decision to choose to enable it.

I actually just tested it to confirm, and add-ons installed from the distribution/extensions directory (with extensions.installDistroAddons set to true) do not appear to be subject to these same restrictions; the add-on I tested was just silently installed and automatically enabled, without any indication.

On a fundamental level, I just don't believe that external software should be able to install add-ons to the browser like this. As a user, I shouldn't have to worry about extensions being silently installed without my direct, explicit consent/permission. Just because I install a program to do one thing doesn't necessarily mean I want it to do another thing as well.

You're right that the distribution directory is within the installation directory, which is good, and in an ideal world, that would be enough - but due to how broken the desktop security model currently is, I just don't think it is (as evident by the fact that packages like these langpack ones are able to install these extensions like this in the first place).

For example, I've seen anti-virus software on Windows in the past abuse functionality like this to forcibly install their extensions, and I know functionality like this has also been abused by adware/malware in the past (This example is obviously old, but it shows how this type of functionality can be abused). Of course, if a system is compromised like this, there's a lot more to worry about than just the browser or any potentially installed browser extensions, but I don't see why we shouldn't try to mitigate/protect against it as much as possible, if that makes sense.

So I'm not sure that this is the best solution to this problem - but this is indeed a problem that we need to address. Will have to do some testing/research and figure out the best way forward.

@degausser wrote in https://codeberg.org/celenity/Phoenix/issues/309#issuecomment-16716107: > the user is in control here, via their package manager. They *might* be in control there, but I don't think that's something we can/should safely assume or guarantee. For example, if I install an add-on from `https://addons.mozilla.org` within the browser, obviously I'm making the conscious, direct, informed decision to install that add-on. Even if I copy an extension to my profile directory from outside the browser, Firefox displays a warning and doesn't enable the extension by default, which allows me as a user to make the conscious decision to choose to enable it. I actually just tested it to confirm, and add-ons installed from the `distribution/extensions` directory *(with `extensions.installDistroAddons` set to `true`)* do not appear to be subject to these same restrictions; the add-on I tested was just silently installed and automatically enabled, without any indication. On a fundamental level, I just don't believe that external software should be able to install add-ons to the browser like this. As a user, I shouldn't have to worry about extensions being silently installed without my direct, explicit consent/permission. Just because I install a program to do one thing doesn't necessarily mean I want it to do another thing as well. You're right that the `distribution` directory is within the installation directory, which is good, and in an ideal world, that would be enough - but due to how broken the desktop security model currently is, I just don't think it is *(as evident by the fact that packages like these langpack ones are able to install these extensions like this in the first place)*. For example, I've seen anti-virus software on Windows in the past abuse functionality like this to forcibly install their extensions, and I know functionality like this [has also been abused by adware/malware in the past](https://forums.mozillazine.org/viewtopic.php?t=948945) *(This example is obviously old, but it shows how this type of functionality can be abused)*. Of course, if a system is compromised like this, there's a lot more to worry about than just the browser or any potentially installed browser extensions, but I don't see why we shouldn't try to mitigate/protect against it as much as possible, if that makes sense. So I'm not sure that this is the best solution to this problem - but this is indeed a problem that we need to address. Will have to do some testing/research and figure out the best way forward.

celenity referenced this issue from a commit

2026-06-08 03:32:03 +02:00

fix: Ensure we use the system locale by default (instead of just using the default locale of the Firefox build)

celenity commented

2026-06-08 07:00:20 +02:00

Owner

FYI @degausser After some research and testing, I was able to come up with a creative work-around to solve this problem, without needing to enable extensions.installDistroAddons or download/install all language packs - 9bb851d702.

Basically, my findings were that:

Setting intl.locale.requested to an empty string sets Firefox's locale to match the system locale.
- If a language pack/locale isn't available for the system locale, Firefox will just fall-back to the default locale (which for most builds like this is en-US)
- Mozilla seems to set this to an empty string by default for GeckoView and their desktop multilingual builds (Not sure why it isn't just the default everywhere TBH).
As long as intl.multilingual.aboutWelcome.languageMismatchEnabled is true (as well as intl.multilingual.downloadEnabled and intl.multilingual.enabled), simply loading about:welcome causes Firefox to download the language pack for the system's locale.

So, basically my solution is:

We now set intl.locale.requested to an empty string by default.
We now also explicitly set intl.multilingual.aboutWelcome.languageMismatchEnabled to true (We already set intl.multilingual.downloadEnabledandintl.multilingual.enabledtotrue`).
On Phoenix's first run (or later if browser.phoenix.localeSetup.shouldRun is set to true):
- We temporarily enable about:welcome.
- We temporarily configure about:welcome to do nothing but display an empty page (via browser.aboutwelcome.screens).
- We load about:welcome in a background tab (via temporarily overriding browser.startup.homepage).
  - We also have logic to ensure that if browser.startup.homepage has a user value, we respect/restore that value.
- We reset intl.locale.requested (so that it always follows our default value of an empty string) to be safe and ensure the locale is properly applied.
After Phoenix's first run, if necessary, we restore the value of browser.startup.homepage.

And that's it. So this effectively makes Firefox automatically download the language pack for the system locale on first run, and our value of an empty string for intl.locale.requested makes it automatically apply the downloaded locale as well.

So not perfect, but overall I think this is a good solution to this problem for the time being.

FYI @degausser After some research and testing, I was able to come up with a creative work-around to solve this problem, without needing to enable `extensions.installDistroAddons` or download/install all language packs - https://codeberg.org/celenity/Phoenix/commit/9bb851d7023499544c24b5659b8a563e4eacacc1. Basically, my findings were that: - Setting `intl.locale.requested` to an empty string sets Firefox's locale to match the system locale. - If a language pack/locale isn't available for the system locale, Firefox will just fall-back to the default locale *(which for most builds like this is `en-US`)* - Mozilla seems to set this to an empty string by default for GeckoView and their desktop multilingual builds *(Not sure why it isn't just the default everywhere TBH)*. - As long as `intl.multilingual.aboutWelcome.languageMismatchEnabled` is `true` *(as well as `intl.multilingual.downloadEnabled` and `intl.multilingual.enabled`)*, simply *loading* `about:welcome` causes Firefox to download the language pack for the system's locale. So, basically my solution is: - We now set `intl.locale.requested` to an empty string by default. - We now also explicitly set `intl.multilingual.aboutWelcome.languageMismatchEnabled` to `true` *(We already set intl.multilingual.downloadEnabled` and `intl.multilingual.enabled` to `true`)*. - On Phoenix's first run *(or later if `browser.phoenix.localeSetup.shouldRun` is set to `true`)*: - We temporarily enable `about:welcome`. - We temporarily configure `about:welcome` to do nothing but display an empty page *(via `browser.aboutwelcome.screens`)*. - We load `about:welcome` in a background tab *(via temporarily overriding `browser.startup.homepage`)*. - We also have logic to ensure that if `browser.startup.homepage` has a user value, we respect/restore that value. - We reset `intl.locale.requested` *(so that it always follows our default value of an empty string)* to be safe and ensure the locale is properly applied. - After Phoenix's first run, if necessary, we restore the value of `browser.startup.homepage`. And that's it. So this effectively makes Firefox automatically download the language pack for the system locale on first run, and our value of an empty string for `intl.locale.requested` makes it automatically apply the downloaded locale as well. So not perfect, but overall I think this is a good solution to this problem for the time being.

celenity closed this issue

2026-06-08 07:00:28 +02:00

celenity referenced this issue from a commit

2026-06-08 07:34:34 +02:00

fix - DESKTOP: Automatically download and apply the language pack for the user's system locale upon initial set-up - fixes https://codeberg.org/celenity/Phoenix/issues/309

celenity referenced this issue from a commit

2026-06-08 07:56:36 +02:00

fix: Improve locale handling

celenity referenced this issue from librewolf/settings

2026-06-08 07:59:34 +02:00

fix: Improve locale handling #136

degausser commented

2026-06-08 19:08:04 +02:00

Author

@celenity

	/// Disable `about:welcome`/onboarding
	`// Privacy concerns - unsolicited connections`

is this no longer a concern, if it happens without user knowledge on firstrun, in a background tab?

@celenity https://codeberg.org/celenity/Phoenix/src/commit/9bb851d7023499544c24b5659b8a563e4eacacc1/phoenix-unified.cfg#L525-526 is this no longer a concern, if it happens without user knowledge on firstrun, in a background tab?

celenity commented

2026-06-09 02:00:55 +02:00

Owner

@degausser wrote in #309 (comment):

is this no longer a concern, if it happens without user knowledge on firstrun, in a background tab?

No, I don't believe it's a concern here because of one key point with this work-around:

We temporarily configure about:welcome to do nothing but display an empty page (via browser.aboutwelcome.screens)

Thanks to us setting browser.aboutwelcome.screens to an empty array, about:welcome effectively does nothing beside download the language pack - which I think is reasonable because the language pack is downloaded from AMO, just like uBlock Origin and Multi-Account Containers (which we install from policies) - so we're not introducing any new parties either.

@degausser wrote in https://codeberg.org/celenity/Phoenix/issues/309#issuecomment-16840895: > is this no longer a concern, if it happens without user knowledge on firstrun, in a background tab? No, I don't believe it's a concern here because of one key point with this work-around: > We temporarily configure `about:welcome` to do nothing but display an empty page *(via `browser.aboutwelcome.screens`)* Thanks to us setting `browser.aboutwelcome.screens` to an empty array, `about:welcome` effectively does nothing beside download the language pack - which I think is reasonable because the language pack is downloaded from AMO, just like uBlock Origin and Multi-Account Containers *(which we install from policies)* - so we're not introducing any new parties either.

celenity referenced this issue from celenity/Dove

2026-06-09 03:06:17 +02:00

[BUG] Language pack handling #73

any1here referenced this issue from a commit

2026-06-09 19:33:12 +02:00

fix: Improve locale handling

Rows
Columns

[OTHER] Reconsider extensions.installDistroAddons->false #309

Please explain your inquiry.

[OTHER] Reconsider `extensions.installDistroAddons->false` #309