Closed Bug 1742892 Opened 2 months ago Closed 1 month ago

Add UI for Fission-specific dom.ipc.processCount.webIsolated to replace "Content process limit" option in the preferences/settings

Categories

(Firefox :: Preferences, task)

Firefox 94
task

Tracking

()

RESOLVED WONTFIX

People

(Reporter: etrapani, Unassigned)

References

Details

If the fission experiment is active the user cannot longer change the Content process limit because the option is missing, after turning off Use recommended performance settings. The only available option is Use hardware acceleration when available.

Removing these associated preferences from prefs.js restores the normal behaviour:

user_pref("fission.experiment.max-origins.last-disqualified", 0);
user_pref("fission.experiment.max-origins.last-qualified", 1637795116);
user_pref("fission.experiment.max-origins.qualified", true);
user_pref("fission.experiment.startupEnrollmentStatus", 4);

Tested with a clean profile. Steps to reproduce (Linux):

$ mkdir /tmp/clean_profile
$ firefox --profile /tmp/clean_profile

Quit, add the settings above to /tmp/clean_profile/prefs.js (otherwise automatically added by the experiment) and run again:

$ firefox --profile /tmp/clean_profile

and after unticking Use recommended performance settings the Content process limit option is missing. Removing the added preferences restores the normal UI.

This just happened to a normal user running Firefox 94 (main release) on a pretty old computer, while trying to modify the default content process limit so that Firefox properly runs there.

This is intentional. Those pref values indicate fission was enabled by the rollout. That limit on content processes doesn't work when fission is enabled. Chris, I assume we've looked at providing some kind of control over fission content process creation and decided against it?

Status: NEW → RESOLVED
Closed: 2 months ago
Flags: needinfo?(cpeterson)
Resolution: --- → INVALID

There is no indication to the user, that in this case wasn't even aware the experiment was active ... (actually the user didn't know about experiments at all, but found that the support article Firefox's performance settings had an extra option that was not being shown). Please remember that this was a completely new user with a pristine profile.

Could you still show the option to set the number of processes, but greyed out? To just remove it from the UI makes it difficult to know what happened. A new user without knowledge of experiments has no way of knowing what is wrong (related to the support article) in one new Firefox compared to another new Firefox. It took quite some time for me to find out what the actual issue was.

I think that experiments should be allowed to do only so much behind the scenes without letting the users know. Silently removing parts of the UI should probably not be among the available options, taking into account that users might not even know they are running experiments, let alone know what they might be doing.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Like Gijs said, the "Content process limit" option UI is not relevant for Fission, so the UI is hidden when Fission is enabled (bug 1685961).

Fission doesn't have settings that are intended for users to change, but you can increase the dom.ipc.processCount.webIsolated pref to improve responsiveness at the cost of more memory (or set it to 1 to use fewer processes at the cost of less responsiveness and perhaps more out-of-memory crashes). Perhaps we could add UI for this pref. I'll ask the team.

Those fission.experiment. prefs will be removed in bug 1732358.

Fission Milestone: --- → ?
Flags: needinfo?(cpeterson)
OS: Linux → All
Hardware: x86_64 → All
See Also: → 1685961
Summary: fission experiment removes needed element from the UI → Fission experiment removes "Content process limit" option from the UI

(In reply to Eduardo Trápani from comment #2)

Could you still show the option to set the number of processes, but greyed out?

That just makes it more confusing - why is the option greyed out? It would extend the same confusion that happened to this user who read the support article and looked at the prefs, which necessarily must be a smaller set of people than the people who would only notice the greyed out preferences.

To just remove it from the UI makes it difficult to know what happened.

The only way to know it disappeared would be to be aware the UI used to exist, either by a support article or because you used it in the past.

I think that experiments should be allowed to do only so much behind the scenes without letting the users know. Silently removing parts of the UI should probably not be among the available options, taking into account that users might not even know they are running experiments, let alone know what they might be doing.

Unfortunately that isn't a realistic possibility. In this case, the experiment is part of the rollout of fission, which is pretty well-documented (cf. https://www.zdnet.com/article/firefox-testing-site-isolation-feature-that-puts-each-site-into-a-separate-process/ , https://www.securityweek.com/mozilla-rolling-out-site-isolation-release-firefox-94 etc. etc.).

If experiments or roll-outs could never hide or change UI, that would make running most experiments or roll-outs impossible, which increases the risk that we ship code, features or UI that doesn't work for significant proportions of the userbase. It also ignores the fact that our UI (especially the preferences/settings UI) already has different options in different locations, with some features like credit card and address autofill being available in the US but not in Europe, for instance. That's unrelated to experiments, but it's quite possible that if/when we want to introduce such features in other places, we'll do a gradual rollout then to make sure we catch bugs before exposing things to 100% of users, and then the same situation could occur with those settings. Restrictions on that type of thing would just lead to worse software for everyone in the end.

Summary: Fission experiment removes "Content process limit" option from the UI → Add UI for Fission-specific dom.ipc.processCount.webIsolated to replace "Content process limit" option in the preferences/settings

(In reply to Chris Peterson [:cpeterson] from comment #3)

Perhaps we could add UI for this pref. I'll ask the team.

What was the outcome of this conversation?

Flags: needinfo?(cpeterson)

Fission is now the default in the Firefox Release channel. Thus we won't be running any more Fission experiments, so the issue where we hid the "Content process limit" setting UI is no longer relevant. However, we now have a documentation bug because SUMO still mentions the setting. I will remove mention of the "Content process limit" setting from this SUMO article:

https://support.mozilla.org/en-US/kb/performance-settings

The Fission team has decided that, for now, we don't want to expose any Fission settings in the UI. Advanced users can tweak their about:config prefs, though that is not recommended. For future reference:

  • If your machine has very little RAM, you want to reduce the number of processes Fission uses by setting the dom.ipc.processCount.webIsolated pref to 1. Every tab and iframe from a given site will share one process. However, this change increases likelihood of unresponsive tabs and out-of-memory tab crashes because more tabs will be squeezing into the same process.
  • If your machine has a lot of RAM, you might benefit from increasing the dom.ipc.processCount.webIsolated pref to a big number like 99. Every tab and iframe will get its own process (up to 99 or whatever). This change might improve tab responsiveness and prevent one tab crash from crashing other tabs, but Firefox will use use a lot more memory.
Flags: needinfo?(cpeterson)

(In reply to Chris Peterson [:cpeterson] from comment #6)

Fission is now the default in the Firefox Release channel. Thus we won't be running any more Fission experiments, so the issue where we hid the "Content process limit" setting UI is no longer relevant. However, we now have a documentation bug because SUMO still mentions the setting. I will remove mention of the "Content process limit" setting from this SUMO article:

https://support.mozilla.org/en-US/kb/performance-settings

Chris, when did this change for all Firefox release users? For me (Windows, en-us) I see the "Content process limit" UI in Firefox version 93 but not in the latest Firefox version 94.0.2. I made a revision to the https://support.mozilla.org/en-US/kb/performance-settings article with different content {for fx94} (Firefox 94 and above, no "Content process limit" settings) and {for not fx94} (Firefox 93 and below still show these settings).

(In reply to Alice Wyman from comment #7)

(In reply to Chris Peterson [:cpeterson] from comment #6)

Fission is now the default in the Firefox Release channel. Thus we won't be running any more Fission experiments, so the issue where we hid the "Content process limit" setting UI is no longer relevant. However, we now have a documentation bug because SUMO still mentions the setting. I will remove mention of the "Content process limit" setting from this SUMO article:

https://support.mozilla.org/en-US/kb/performance-settings

Chris, when did this change for all Firefox release users? For me (Windows, en-us) I see the "Content process limit" UI in Firefox version 93 but not in the latest Firefox version 94.0.2. I made a revision to the https://support.mozilla.org/en-US/kb/performance-settings article with different content {for fx94} (Firefox 94 and above, no "Content process limit" settings) and {for not fx94} (Firefox 93 and below still show these settings).

  • needinfo for this.
Flags: needinfo?(cpeterson)

I'm not sure if this is the place to ask, but whether the preference is exposed in the UI or not, will it be honored for those users who had set it? I administer many old machines, all of them with content process limit set to 1, because otherwise they would be unusable.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Eduardo Trápani from comment #9)

I'm not sure if this is the place to ask, but whether the preference is exposed in the UI or not, will it be honored for those users who had set it? I administer many old machines, all of them with content process limit set to 1, because otherwise they would be unusable.

I think Chris is in a better position to answer this than me. This bug got filed for the visual aspect of the preference and I don't know whether there's any migration happening from the old pref to the new one - they don't necessarily translate one-to-one.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Alice Wyman from comment #7)

Chris, when did this change for all Firefox release users? For me (Windows, en-us) I see the "Content process limit" UI in Firefox version 93 but not in the latest Firefox version 94.0.2. I made a revision to the https://support.mozilla.org/en-US/kb/performance-settings article with different content {for fx94} (Firefox 94 and above, no "Content process limit" settings) and {for not fx94} (Firefox 93 and below still show these settings).

Your change to use {for fx94} and {for not fx94} on the https://support.mozilla.org/en-US/kb/performance-settings article is good. Thank you! My article edit had just deleted information about the "Content process limit" settings, but I see now that the information is still relevant for users on older Firefox versions (such as ESR 91).

The "Content process limit" UI is hidden if Fission is enabled and, as of today, Fission should be enabled for 100% of Firefox 94.0.2 and 95.0 users on the Release channel.

Fission is enabled for only 25% of Firefox 94.0 and 94.0.1 users, but we can assume those users will update to 94.0.2 or 95.0 soon. No need to make the support article differentiate between 94.0, 94.0.1, and 94.0.2.

Flags: needinfo?(cpeterson)

(In reply to Eduardo Trápani from comment #9)

I'm not sure if this is the place to ask, but whether the preference is exposed in the UI or not, will it be honored for those users who had set it?

Good question. The "Content process limit" setting is now hidden because it's no longer relevant with Fission (aka "Site Isolation"). Before Fission, Firefox load balanced tabs across 1-8 content processes, no matter how many tabs you had open. With Fission, every site gets its own content processes, so the total number of content processes is unbounded. If you open more sites, Fission needs to use more content processes.

I administer many old machines, all of them with content process limit set to 1, because otherwise they would be unusable.

You can't limit the total number of content processes Fission will use, but you can limit the number of content processes Fission will use per site by setting the dom.ipc.processCount.webIsolated pref (the default is 4). But as described in comment 6 above, decreasing or increasing that number has trade-offs.

For example, with dom.ipc.processCount.webIsolated = 4, if you open 1-4 YouTube tabs, Fission will use 1-4 YouTube content processes. If you open a fifth YouTube tab, Fission will load balance the new YouTube tabs across 4 YouTube content processes.

If you change dom.ipc.processCount.webIsolated to 1, then all YouTube tabs will all share one content process. That might reduce Firefox's total memory usage some, but those YouTube tabs will all become less responsive and more likely to hit out-of-memory crashes because they have to squeeze into one content process. Each YouTube tab will have less memory and CPU time available.

I think the memory overhead of each content process is only about 20 KB, so there is really not much benefit to decreasing dom.ipc.processCount.webIsolated.

The severity field is not set for this bug.
:jaws, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jaws)
Severity: -- → N/A
Status: REOPENED → RESOLVED
Type: defect → task
Closed: 2 months ago1 month ago
Flags: needinfo?(jaws)
Resolution: --- → WONTFIX
Fission Milestone: ? → ---
You need to log in before you can comment on or make changes to this bug.