1732358 - Enable Fission pref by default in Firefox 97

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, task, P2)

Description

[Chris Peterson [:cpeterson]]

The Fission rollout will enroll Firefox 94 and 95 users. We will pref on Fission by default in Firefox 96.

The rollout sets the fission.experiment.enrollmentStatus pref = 4. This bug needs to:

1. Set the default pref fission.autostart = true.
2. Remove the now-unneeded experiment prefs fission.experiment.enrollmentStatus and fission.experiment.startupEnrollmentStatus and supporting code.
3. Remove Fission from the Settings' Nightly Experiments: about:preferences#experimental. This was added in https://hg.mozilla.org/mozilla-central/rev/b6766d19d621 by bug 1652134.
4. Add our rollout slug (bug-1732206-rollout-fission-release-rollout-release-94-95) to this list of graduated rollouts (GRADUATION_SET) here (because we're using different prefs for the rollout and enabling by default):

https://searchfox.org/mozilla-central/rev/f62d42b1d98e67dc3da05d586f71103df02b8c4a/toolkit/components/normandy/lib/PreferenceRollouts.jsm#128-137

The rollout slug will need to stay in the graduation set forever. If a user gets enrolled in the rollout in Firefox 95, stops using it for a while, and then starts using the browser again in a version > 96, then we want to make sure that the Normandy instruction to graduate from the rollout is still present in versions > 96.

Comment 1

[KOLANICH]

Fission has increased memory consumption and I'd prefer it to be disabled. No mitigation measures worth increased memory consumption. Rolling out fission makes only sense to the users having great underutilization of physical memory. Otherwise they would experience different issues, like oom crashes (not necessarily of firefox processes, usually it is other processes that crash), very poor performance (including the effects known as linux kernel bug 12309 (which is, though marked as fixed, is not really fixed)) and increased storage device wear because of swapping. TBH, I already experience such issues on Linux even if fissix is disabled, because Linux is not ntoskrnl.exe and was not developed as a commercial proprietary kernel for a commercial proprietary OS which licenses are sold to desktop users to worth the costs of improving the memory manager and io the way to eliminate 12309.

In order to determine if there is RAM underutilisation it it would require a daemon collecting statistics of memory usage (under a memory consumption by a program I also mean consumption by its child processes, except the cases when they are started explicitly by a user from the programs intended to provide UI for starting other programs). It has to be active even if Firefox is closed, because a user may have memory-demanding programs open before launching Firefox. Fissix can be enabled if and only if it was determined that it will not break usage patterns of the user. It also makes sense to be able to switch fission on and off in runtime without restarting firefox, because a user can start Firefox first, and then a memory-demanding program. If this feature is implemented improperly, it can allow a malicious webpages to undo fissix by increasing own memory consumption. So, only the amount of memory consumed by Firefox processes themselves should be used to decide if to use fissix. Also, it may make sense to explicitly ask a user about his tradeofs in a form of dialog with a text like "Firefox has a feature called fissix, which mitigates some attacks and improves your cybersecurity, at the cost of greater memory consumption. We have determined that enabling fissix is not going to break your usage patterns and suggest you to enable it. Currently your physical memory amount available to software you start is ..., maximum memory usage by other software is ... (... % of available), maximum memory usage of Firefox in non-fissix mode is ... (...%) (assumming your usage patterns, ... tabs on average, you can open ... tabs additionally), maximum memory usage in fissix mode would be .... (...% of available, you would be able to open ... tabs additionally), so you won't be able to run the programs consuming in total not less than ... (...%).", then either "We don't remember you running any such programs, but you have run ... consuming ... (...% of available after Firefox)" or "We remember you running such a program (...), but you already cannot run them simultaneously with Firefox, you have also run ... and they are not going to be broken." and the 3 options, 1 to enable fissix, 1 to disable fissix and 1 to delay the decision.

Comment 2

[KOLANICH]

Of course, not fissix, but fission. fissix is a python lib I have recently used.

Comment 3

[Darkspirit]

(In reply to KOLANICH from comment #1)
The other perspective is that a web browser is intimidatingly complex, there is only this way to protect tabs against each other and it's an architectural redesign, not just a feature.
Please check if a properly configured https://addons.mozilla.org/firefox/addon/auto-tab-discard/ improves your experience.
(bug 1532955/bug 1475889/bug 1730209 go in a similar direction.)
For the general Linux problem, earlyoom could be an improvement:
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-32-Default-EarlyOOM
https://packages.debian.org/stable/earlyoom

Comment 4

[KOLANICH]

Thanks for the advice, I have already tried userspace OOM-killers. They are not useful, they kill existing processes, I had to get rid of them. The only thing that makes my linux experience somehow bearable is zram + disabling of overcommit (at least I don't have to hit reset button) + relatively large amount of physical RAM (8 GiB, but I have linux machines with 2 GiBs and even 512 MiBs which run extremily obsolete versions of software (on Windows 7 32-bit 2 GiB feels OK (even with Fission, though Process Explorer tree becomes a mess), if one disables Windows Update service, which consumes lot of RAM due to unknown reason) ). It causes the processes crahing and failing to start though and my XOrg session crashes several times a day (Wayland one crashes immediately after Firefox being started, even with overcommit enabled, it may likely be a KDE bug).

it's an architectural redesign, not just a feature.

Yeah, it is an architectural design. But the benefits it brings is a feature.

The other perspective is that a web browser is intimidatingly complex, there is only this way to protect tabs against each other

One cannot protect tabs from each other at all. It is impossible. I.e. one tab can purportedly consume large amount of any limited resource in order to disrupt operation of other tabs and programs or measurably degrade their operation, so it can be used as a side channel. I even once (long ago) encountered a PoC using WebGL causing DoS (by just feeding large amount of triangles) on GPU drivers, so I had to use reset button to restart the OS.

Instead of trying to fix unfixable by technical means browser developers should concentrate on standards allowing community to use organizational means to prevent bad behavior. Not protection from Spectre using mitigations that will not work against future variants of Spectre, but not running any malicious code looking like the oje exploiting Spectre on websites at all. I am not advocating creation of a central authority signing JS code, like Mozilla has done for WebExtensions for Firefox, but a lot simpler solution. Each library must be just a separate package using by multiple websites. It must be installed into the browser itself. And regular websites must not be allowed to execute any Turing-complete code. If they need it, author must publish it under a free license (no proprietary Turing-complete code allowed ever, the code must have machine-readable metadata, and stating in that metadata that the code is licensed under, say, MIT license, must mean that it is really so, and users are explicitly allowed to reverse engineer the code and replace it with own implementation, so no adversary should be able to coerce users into using his malicious module) by a static URI (content-addressible) and then use the published package, if a user has explicitly aggreed to install it into the browser. React/Svelte/Angular/Vue/JQuery/things like these would quickly be installed into each browser, and everything else, like fingerprint.js would only cause WTF!? reaction (especially if a fake of fingerprint.js feeding websites with plausible-looking misinformation was preinstalled by a browser vendor).

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to KOLANICH from comment #1)

Fission has increased memory consumption and I'd prefer it to be disabled. No mitigation measures worth increased memory consumption. Rolling out fission makes only sense to the users having great underutilization of physical memory.

In our Firefox user experiments measuring Fission's memory usage, we see total memory usage increase an average of only about 3%. Though some individual websites with lots of ads can use more memory with Fission than before, some websites will actually use less memory with Fission because multiple tabs with the same website loaded will share processes. For example, without Fission, opening ten Google Docs tabs will use eight processes. With Fission, ten Google Docs tabs will share just four processes (or whatever the value of the dom.ipc.processCount.webIsolated pref is).

After the fission.autostart pref is removed, you can still reduce the memory overhead of Fission:

• Set the dom.ipc.processCount.webIsolated pref to 1. This will reduce the number of processes that Fission launches for each website.
• Set the fission.webContentIsolationStrategy pref to 0. This is the closest setting to disabling Fission. Every website will share one process, though Fission will still isolate extensions and Firefox's internal pages (like about:config).
• Install an ad blocker. This will prevent ads from causing Fission to launch more processes.

Comment 6

[KOLANICH]

Thanks a lot for the advice, I haven't been knowing about these prefs and should really try them and learn them. About content blockers - I already use them extensively ;)

Comment 7

[Andrew Halberstadt [:ahal]]

Hsin-Yi and I realized this will need to block on bug 1736859. It's on Releng's expedite track and we're hoping to have it done before the 96 merge day.

Comment 8

[Chris Peterson [:cpeterson]]

The current plan is to enable the fission.autostart pref early in the Nightly 97 cycle.

I'm tentatively assigning this bug to Nika to give her the honor of flipping the pref. :)

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1732358 - Part 1: Override required_prefs in test_fission_autostart.py, r=kmag,whimboo

Unfortunately we currently always configure the "fission.autostart" pref when
running tests, meaning that the test_fission_autostart.py test is always being
skipped on all platforms. This change force-disables the required pref when
running the test, rather than skipping the test if it is set.

It would be nice to handle this in a less hacky way, but this was the first way
I could think of.

Comment 10

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1732358 - Part 2: Add the ability to force-disable fission with an environment variable, r=kmag,ahal

This is required to replace the existing MOZ_FORCE_ENABLE_FISSION environment
variables in environments which use that. In the future we'll want to stop
passing any environment variable when not passing a flag to ./mach run
however that will require changes to the default test behaviour in bug 1744091.

Depends on D133005

Comment 11

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1732358 - Part 3: Remove fission from the experimental features pane in about:preferences, r=cpeterson

Fission will be enabled by default in the next part, and no longer needs to be
listed as an experimental feature.

Depends on D133006

Comment 12

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1732358 - Part 4: Enable fission by default on non-android platforms, r=kmag

This requires changing the behaviour of test_fission_autostart.js to handle the
new default value.

Depends on D133007

Comment 13

[Chris Peterson [:cpeterson]]

Nika, you also need to add the Fission Release rollout slug to Normandy's graduation set. Ask r=mythmon for code review. Later we will need to add the Fission Beta 96 rollout slug (bug 1745237) to the graduation set.

3. Add our rollout slug (bug-1732206-rollout-fission-release-rollout-release-94-95) to this list of graduated rollouts (GRADUATION_SET) here (because we're using different prefs for the rollout and enabling by default):

https://searchfox.org/mozilla-central/rev/f62d42b1d98e67dc3da05d586f71103df02b8c4a/toolkit/components/normandy/lib/PreferenceRollouts.jsm#128-137

The rollout slug will need to stay in the graduation set forever. If a user gets enrolled in the rollout in Firefox 95, stops using it for a while, and then starts using the browser again in a version > 96, then we want to make sure that the Normandy instruction to graduate from the rollout is still present in versions > 96.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1732358 - Part 5: Add the fission rollout slug to the GRADUATION_SET, r=mythmon

Depends on D133008

Comment 15

[Nika Layzell [:nika] (ni? for response)]

I've pushed a new patch which adds that item to the set.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f341c2c8bbee
Part 1: Override required_prefs in test_fission_autostart.py, r=whimboo,mccr8
https://hg.mozilla.org/integration/autoland/rev/6a8175e7c32b
Part 2: Add the ability to force-disable fission with an environment variable, r=ahal,fluent-reviewers,flod,mccr8
https://hg.mozilla.org/integration/autoland/rev/abc668080c89
Part 3: Remove fission from the experimental features pane in about:preferences, r=cpeterson,preferences-reviewers
https://hg.mozilla.org/integration/autoland/rev/bcf5711345c0
Part 4: Enable fission by default on non-android platforms, r=annyG,peterv,pbone,cpeterson
https://hg.mozilla.org/integration/autoland/rev/d6e8528f0a93
Part 5: Add the fission rollout slug to the GRADUATION_SET, r=mythmon

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/f341c2c8bbee
https://hg.mozilla.org/mozilla-central/rev/6a8175e7c32b
https://hg.mozilla.org/mozilla-central/rev/abc668080c89
https://hg.mozilla.org/mozilla-central/rev/bcf5711345c0
https://hg.mozilla.org/mozilla-central/rev/d6e8528f0a93