[OTHER] Some changed [DEFAULT]s #280

degausser commented 2026年04月27日 22:19:45 +02:00

Please explain your inquiry.

some prefs that are now true by default (should remain false in Phoenix):

Ship Reporting API (bugzilla) [149+]
dom.reporting.enabled
dom.reporting.header.enabled

Enable trustPanel on release (bugzilla) [149+]
browser.urlbar.trustPanel.featureGate

### Please explain your inquiry. some prefs that are now `true` by default _(should remain `false` in Phoenix)_: [Ship Reporting API (bugzilla)](https://bugzilla.mozilla.org/show_bug.cgi?id=1976074) [149+] dom.reporting.enabled dom.reporting.header.enabled [Enable trustPanel on release (bugzilla)](https://bugzilla.mozilla.org/show_bug.cgi?id=2008405) [149+] browser.urlbar.trustPanel.featureGate

degausser commented 2026年04月28日 13:29:23 +02:00

instead of checking manually, I went over diffs FF144-FF149 from arkenfox, here are select changes:

• values in phoenix now being upstream [DEFAULT]

browser.ipProtection.features.siteExceptions
browser.newtabpage.activity-stream.discoverystream.config
browser.newtabpage.activity-stream.discoverystream.imageProxy.enabled
browser.newtabpage.activity-stream.discoverystream.publisherFavicon.enabled
browser.newtabpage.activity-stream.discoverystream.sections.customizeMenuPanel.enabled
browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled
browser.newtabpage.activity-stream.telemetry.privatePing.redactNewtabPing.enabled
browser.profiles.enabled
browser.safebrowsing.provider.google5.enabled
pdfjs.enableAltText [DEFAULT - non-Android]
pdfjs.enableAltTextModelDownload [DEFAULT - non-Android]
pdfjs.enableGuessAltText [DEFAULT - non-Android]
pdfjs.enableHWA [DEFAULT - non-Android]
privacy.bounceTrackingProtection.requireStatefulBounces
security.certerrors.felt-privacy-v1 // also no longer [HIDDEN]

• values in phoenix that got flipped upstream and are no longer [DEFAULT] (but phoenix values should be kept)

browser.newtabpage.activity-stream.discoverystream.reportAds.enabled [->true] // also no longer NIGHTLY
browser.newtabpage.activity-stream.telemetry.privatePing.enabled [->true]
browser.urlbar.trustPanel.featureGate [->true]
dom.reporting.enabled [->true]
dom.reporting.header.enabled [->true]
extensions.openPopupWithoutUserGesture.enabled [->true] // also no NIGHTLY/release distinction

• removed prefs (to be tagged as [ESR]). all of these got removed from init/all.js / firefox.js / StaticPrefs.yaml, but some may still be set/read by nimbus (*), i'm not sure

browser.crashReports.crashPull
browser.newtabpage.activity-stream.discoverystream.merino-provider.enabled
browser.newtabpage.activity-stream.discoverystream.onboardingExperience.dismissed
browser.newtabpage.activity-stream.discoverystream.onboardingExperience.enabled
browser.newtabpage.activity-stream.discoverystream.personalization.enabled *
browser.newtabpage.activity-stream.discoverystream.recs.personalized
browser.newtabpage.activity-stream.discoverystream.spocMessageVariant
browser.newtabpage.activity-stream.discoverystream.spocs.personalized
browser.newtabpage.activity-stream.feeds.recommendationprovider
browser.preferences.experimental *
browser.privatebrowsing.vpnpromourl
extensions.manifestV3.enabled
extensions.webcompat.useScriptingAPI
network.auth.confirmAuth.enabled
network.trr.confirmation_telemetry_enabled
services.sync.prefs.sync.browser.urlbar.update2.engineAliasRefresh

• old AI prefs. it's my understanding that browser.aiwindow.* got migrated to browser.smartwindow.* wholesale, and browser.ml.smartAssist.* got removed. since these are not present in firefox 140 esr, these could be removed completely

browser.aiwindow.*
browser.ml.smartAssist.*

• AI memories (ex-"insights") switch got split into two, so browser.smartwindow.memories should be removed, and new prefs added for parity

browser.smartwindow.memories.generateFromConversation->false
browser.smartwindow.memories.generateFromHistory->false

• finally, 3 weird pref changes

security.disallow_privilegedabout_remote_script_loads is now upstream false, but the check for the pref itself got flipped as well, bugzilla mentioning crashes

network.lna.etp.enabled - the source code reflects the reasoning in phoenix, however this then doesn't make much sense. also for 149, they enabled it for etp strict by toggling it to true - is it nimbus dependent?

network.trr.retry_on_recoverable_errors - this got mentioned in librewolf preferences cleanup pr as well last year. at least on android this might be undesirable as true due to bugs, upstream is now default false everywhere

---

btw @rusty-snake's firefox-prefs-differ could be utilized (programmatically?) before each phoenix release, to make tracking / updating prefs a bit easier.

instead of checking manually, I went over [diffs FF144-FF149](https://github.com/arkenfox/user.js/issues/2043) from arkenfox, here are select changes: * values in phoenix now being upstream [DEFAULT] ``` browser.ipProtection.features.siteExceptions browser.newtabpage.activity-stream.discoverystream.config browser.newtabpage.activity-stream.discoverystream.imageProxy.enabled browser.newtabpage.activity-stream.discoverystream.publisherFavicon.enabled browser.newtabpage.activity-stream.discoverystream.sections.customizeMenuPanel.enabled browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled browser.newtabpage.activity-stream.telemetry.privatePing.redactNewtabPing.enabled browser.profiles.enabled browser.safebrowsing.provider.google5.enabled pdfjs.enableAltText [DEFAULT - non-Android] pdfjs.enableAltTextModelDownload [DEFAULT - non-Android] pdfjs.enableGuessAltText [DEFAULT - non-Android] pdfjs.enableHWA [DEFAULT - non-Android] privacy.bounceTrackingProtection.requireStatefulBounces security.certerrors.felt-privacy-v1 // also no longer [HIDDEN] ``` * values in phoenix that got flipped upstream and are no longer [DEFAULT] _(but phoenix values should be kept)_ ``` browser.newtabpage.activity-stream.discoverystream.reportAds.enabled [->true] // also no longer NIGHTLY browser.newtabpage.activity-stream.telemetry.privatePing.enabled [->true] browser.urlbar.trustPanel.featureGate [->true] dom.reporting.enabled [->true] dom.reporting.header.enabled [->true] extensions.openPopupWithoutUserGesture.enabled [->true] // also no NIGHTLY/release distinction ``` * removed prefs (to be tagged as [ESR]). all of these got removed from init/all.js / firefox.js / StaticPrefs.yaml, but some may still be set/read by nimbus (*), i'm not sure ``` browser.crashReports.crashPull browser.newtabpage.activity-stream.discoverystream.merino-provider.enabled browser.newtabpage.activity-stream.discoverystream.onboardingExperience.dismissed browser.newtabpage.activity-stream.discoverystream.onboardingExperience.enabled browser.newtabpage.activity-stream.discoverystream.personalization.enabled * browser.newtabpage.activity-stream.discoverystream.recs.personalized browser.newtabpage.activity-stream.discoverystream.spocMessageVariant browser.newtabpage.activity-stream.discoverystream.spocs.personalized browser.newtabpage.activity-stream.feeds.recommendationprovider browser.preferences.experimental * browser.privatebrowsing.vpnpromourl extensions.manifestV3.enabled extensions.webcompat.useScriptingAPI network.auth.confirmAuth.enabled network.trr.confirmation_telemetry_enabled services.sync.prefs.sync.browser.urlbar.update2.engineAliasRefresh ``` - old AI prefs. it's my understanding that browser.aiwindow.* got [migrated](https://searchfox.org/firefox-main/source/browser/components/ProfileDataUpgrader.sys.mjs#933) to browser.smartwindow.* wholesale, and browser.ml.smartAssist.* got removed. since these are not present in firefox 140 esr, these could be removed completely ``` browser.aiwindow.* browser.ml.smartAssist.* ``` - AI memories (ex-"insights") switch got split into two, so `browser.smartwindow.memories` should be removed, and new prefs added for parity ``` browser.smartwindow.memories.generateFromConversation->false browser.smartwindow.memories.generateFromHistory->false ``` - finally, 3 weird pref changes `security.disallow_privilegedabout_remote_script_loads` is now upstream false, but the check for the pref itself got [flipped as well](https://github.com/mozilla-firefox/firefox/commit/ca0fd68d8662), [bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=1987185) mentioning crashes `network.lna.etp.enabled` - the source code reflects the reasoning in phoenix, however [this](https://bugzilla.mozilla.org/show_bug.cgi?id=1991917#c4) then doesn't make much sense. also for 149, they enabled it for etp strict by [toggling it to true](https://bugzilla.mozilla.org/show_bug.cgi?id=2017249) - is it nimbus dependent? `network.trr.retry_on_recoverable_errors` - this got mentioned in librewolf preferences cleanup pr as well last year. at least on android this might be undesirable as true due to [bugs](https://bugzilla.mozilla.org/show_bug.cgi?id=1996813#c7), upstream is now default false everywhere ___ btw @rusty-snake's [firefox-prefs-differ](https://github.com/rusty-snake/firefox-prefs-differ) could be utilized (programmatically?) before each phoenix release, to make tracking / updating prefs a bit easier.

celenity commented 2026年04月28日 23:16:44 +02:00

@degausser

Thank you so much for this issue and taking the time to go through/share these!!

security.certerrors.felt-privacy-v1 // also no longer [HIDDEN]

AFAICT this does still appear to be hidden on Android/Thunderbird, but you're right it is now the default for Desktop, so will add a note to indicate that.

security.disallow_privilegedabout_remote_script_loads is now upstream false, but the check for the pref itself got flipped as well, bugzilla mentioning crashes

Interesting. From the Bugzilla, to me it looks like the logic before was totally broken/reversed, so I'm glad they fixed it. I think their changes in that bug should resolve the crash as well, so I think we can probably keep it set to true for now (Though if there are still crashes or any other issues, we can consider removing it).

network.lna.etp.enabled - the source code reflects the reasoning in phoenix, however this then doesn't make much sense. also for 149, they enabled it for etp strict by toggling it to true - is it nimbus dependent?

So, based on this part of the code, my understanding is that network.lna.etp.enabled just controls whether network.lna.blocking is set via the ContentBlockingPrefs mechanism, based on the presence of lna/-lna in the value of browser.contentblocking.features.strict. If network.lna.etp.enabled is false, I believe that network.lna.blocking will defer to its value at StaticPrefList.yaml.

In regards to the first Bugzilla comment you linked, I believe the reason they claimed that LNA will be disabled when network.lna.etp.enabled is false for ETP Strict and Standard Users is due to network.lna.blocking defaulting to false at StaticPrefList.yaml outside of Nightly. Because Phoenix also sets network.lna.blocking to true directly, LNA should be enabled for us though.

So, basically, if network.lna.etp.enabled is true:

• network.lna.blocking would be set based on the presence of lna or -lna at browser.contentblocking.features.strict
  • So ex. if browser.contentblocking.features.strict contains lna (which it does by default), network.lna.blocking would only be set to true if ETP Strict is enabled

If network.lna.etp.enabled is false:

• The value of network.lna.blocking would just be set from its default value (ignoring ETP/browser.contentblocking.features.strict).
  • So, for stock Release, this would be false, for Nightly and Phoenix users, it'd be true.

This mechanism is fairly complex, and I understand your confusion based on the Bugzilla comment as well, due to it lacking context. So hopefully this makes sense.

network.trr.retry_on_recoverable_errors - this got mentioned in librewolf preferences cleanup pr as well last year. at least on android this might be undesirable as true due to bugs, upstream is now default false everywhere

Fair enough. Based on the code and this comment from the Bugzilla, it looks like that pref only impacts mode 2 anyways (which is meant to allow system fall-back), so I'll just remove it.

I think I'll also remove network.trr.strict_native_fallback as well for similar reasons (unless you have any objections), since it also only seems to impact mode 2. I think disallowing system DNS fall-back from mode 2 defeats the point of using that mode in the first place... - We use 3 by default, so assuming a user does want the system fall-back and goes out of their way to change it to 2, we should probably let that work as expected).

btw @rusty-snake's firefox-prefs-differ could be utilized (programmatically?) before each phoenix release, to make tracking / updating prefs a bit easier.

Interesting... this looks very nice, thanks for sharing it! Will definitely see if we can incorporate this.

@degausser Thank you so much for this issue and taking the time to go through/share these!! > `security.certerrors.felt-privacy-v1 // also no longer [HIDDEN]` AFAICT this does still appear to be hidden on Android/Thunderbird, but you're right it is now the default for Desktop, so will add a note to indicate that. > `security.disallow_privilegedabout_remote_script_loads` is now upstream false, but the check for the pref itself got [flipped as well](https://github.com/mozilla-firefox/firefox/commit/ca0fd68d8662), [bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=1987185) mentioning crashes Interesting. From the Bugzilla, to me it looks like the logic before was totally broken/reversed, so I'm glad they fixed it. I think their changes in that bug *should* resolve the crash as well, so I think we can probably keep it set to `true` for now *(Though if there are still crashes or any other issues, we can consider removing it)*. > `network.lna.etp.enabled` - the source code reflects the reasoning in phoenix, however [this](https://bugzilla.mozilla.org/show_bug.cgi?id=1991917#c4) then doesn't make much sense. also for 149, they enabled it for etp strict by [toggling it to true](https://bugzilla.mozilla.org/show_bug.cgi?id=2017249) - is it nimbus dependent? So, based on [this part of the code](https://searchfox.org/firefox-main/rev/0fa53bd1/browser/components/protections/ContentBlockingPrefs.sys.mjs#254), my understanding is that `network.lna.etp.enabled` just controls whether `network.lna.blocking` is set via the `ContentBlockingPrefs` mechanism, based on the presence of `lna`/`-lna` in the value of [`browser.contentblocking.features.strict`](https://searchfox.org/firefox-main/rev/0fa53bd1/browser/app/profile/firefox.js#2518). If `network.lna.etp.enabled` is false, I believe that `network.lna.blocking` will defer to [its value at `StaticPrefList.yaml`](https://searchfox.org/firefox-release/rev/ec9aaac4/modules/libpref/init/StaticPrefList.yaml#14891). In regards to the first Bugzilla comment you linked, I believe the reason they claimed that LNA will be disabled when `network.lna.etp.enabled` is false for ETP Strict *and* Standard Users is due to `network.lna.blocking` defaulting to `false` at `StaticPrefList.yaml` outside of Nightly. Because Phoenix also sets `network.lna.blocking` to `true` directly, LNA should be enabled for us though. So, basically, if `network.lna.etp.enabled` is `true`: - `network.lna.blocking` would be set based on the presence of `lna` or `-lna` at `browser.contentblocking.features.strict` - So ex. if `browser.contentblocking.features.strict` contains `lna` *(which it does by default)*, `network.lna.blocking` would only be set to `true` if ETP Strict is enabled If `network.lna.etp.enabled` is `false`: - The value of `network.lna.blocking` would just be set from its default value *(ignoring ETP/`browser.contentblocking.features.strict`)*. - So, for stock Release, this would be `false`, for Nightly and Phoenix users, it'd be `true`. This mechanism is fairly complex, and I understand your confusion based on the Bugzilla comment as well, due to it lacking context. So hopefully this makes sense. > `network.trr.retry_on_recoverable_errors` - this got mentioned in librewolf preferences cleanup pr as well last year. at least on android this might be undesirable as true due to [bugs](https://bugzilla.mozilla.org/show_bug.cgi?id=1996813#c7), upstream is now default false everywhere Fair enough. Based on the code and [this comment from the Bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=1996813#c12), it looks like that pref only impacts mode `2` anyways *(which is meant to allow system fall-back)*, so I'll just remove it. I think I'll also remove `network.trr.strict_native_fallback` as well for similar reasons *(unless you have any objections)*, since it also only seems to impact mode `2`. I think disallowing system DNS fall-back from mode `2` defeats the point of using that mode in the first place... - We use `3` by default, so assuming a user does want the system fall-back and goes out of their way to change it to `2`, we should probably let that work as expected). > btw @rusty-snake's firefox-prefs-differ could be utilized (programmatically?) before each phoenix release, to make tracking / updating prefs a bit easier. Interesting... this looks very nice, thanks for sharing it! Will definitely see if we can incorporate this.

degausser commented 2026年04月29日 02:36:48 +02:00

@celenity Thank you for the lna pref explanation, it is clearer to me now.

Last few prefs I missed the first time around:

https://bugzilla.mozilla.org/show_bug.cgi?id=1987352
browser.download.loglevel is now toolkit.download.loglevel. Should the old pref be kept as [ESR] ?

https://bugzilla.mozilla.org/show_bug.cgi?id=1999162
browser.newtabpage.activity-stream.system.trendingSearch.enabled
browser.newtabpage.activity-stream.trendingSearch.enabled
Android has trending search, but it doesn't look like these prefs govern that too; we should be able to remove them altogether, since they are not referenced in ESR.

https://bugzilla.mozilla.org/show_bug.cgi?id=1996171
browser.urlbar.quicksuggest.dataCollection.enabled can be tagged as [ESR] (or we wait for complete removal).

https://bugzilla.mozilla.org/show_bug.cgi?id=1922974
image.jxl.enabled - pref now exists (guarded by define) only in builds with --enable-jxl (Nightly, librewolf)

---

removal of fallbacks for trr.mode=2

No objections here.

@celenity Thank you for the lna pref explanation, it is clearer to me now. Last few prefs I missed the first time around: https://bugzilla.mozilla.org/show_bug.cgi?id=1987352 `browser.download.loglevel` is now `toolkit.download.loglevel`. Should the old pref be kept as [ESR] ? https://bugzilla.mozilla.org/show_bug.cgi?id=1999162 `browser.newtabpage.activity-stream.system.trendingSearch.enabled` `browser.newtabpage.activity-stream.trendingSearch.enabled` Android has trending search, but it doesn't look like these prefs govern that too; we should be able to remove them altogether, since they are not referenced in ESR. https://bugzilla.mozilla.org/show_bug.cgi?id=1996171 `browser.urlbar.quicksuggest.dataCollection.enabled` can be tagged as [ESR] (or we wait for complete removal). https://bugzilla.mozilla.org/show_bug.cgi?id=1922974 `image.jxl.enabled` - pref now _exists_ (guarded by define) only in builds with `--enable-jxl` (Nightly, [librewolf](https://codeberg.org/librewolf/source/src/branch/main/patches/allow-JXL-in-non-nightly-browser.patch)) ___ > removal of fallbacks for trr.mode=2 [No objections here.](https://codeberg.org/librewolf/settings/pulls/97#issuecomment-8827791)

celenity commented 2026年04月29日 08:50:26 +02:00

@degausser Good catches, thanks again!

https://bugzilla.mozilla.org/show_bug.cgi?id=1987352
browser.download.loglevel is now toolkit.download.loglevel. Should the old pref be kept as [ESR] ?

Probably not worth keeping as ESR IMO, since it matches the default value (and the only reason we set it was just to easily expose it at about:config for Android/Thunderbird). Since toolkit.download.loglevel is defined at all.js, I didn't bother adding that pref either.

image.jxl.enabled - pref now exists (guarded by define) only in builds with --enable-jxl

Interesting... I think it's worth keeping so we can still ensure its disabled by default for users with those builds that support it, but I did go ahead and add a note to indicate that its guarded by the MOZ_JXL define.

@degausser Good catches, thanks again! > https://bugzilla.mozilla.org/show_bug.cgi?id=1987352 `browser.download.loglevel` is now `toolkit.download.loglevel`. Should the old pref be kept as [ESR] ? Probably not worth keeping as `ESR` IMO, since it matches the default value *(and the only reason we set it was just to easily expose it at `about:config` for Android/Thunderbird)*. Since `toolkit.download.loglevel` is defined at `all.js`, I didn't bother adding that pref either. > `image.jxl.enabled` - pref now *exists* (guarded by define) only in builds with `--enable-jxl` Interesting... I think it's worth keeping so we can still ensure its disabled by default for users with those builds that support it, but I did go ahead and add a note to indicate that its guarded by the `MOZ_JXL` define.