Open Bug 1400074 Opened 7 years ago Updated 2 years ago

Warn developers who have opted out of multiple processes, and let them opt back in.

Categories

(DevTools :: about:debugging, enhancement, P2)

Product:
DevTools
Component:
about:debugging
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: potch, Unassigned)

References

Details

On about:debugging#workers, we warn "Service Worker debugging is not compatible with multiple content processes at the moment.", and provide an easy button to disable e10s-multi.

We should also be *strongly* warning developers when they have disabled e10s multi that they have degraded their browsing experience, and give them the same 1-click button to opt back in once they are finished debugging.

I worry we are stranding people in opt-out, and they won't know why their Firefox is running poorly, they'll just think we aren't performant.
Severity: normal → enhancement
Priority: -- → P2
This should be pretty easy to do now that we have a single pref "dom.ipc.multiOptOut" to toggle!

The previous implementation was relying on a processCount pref and we initially had a way to "go back" to multi content process, but the implementation got overly complicated for little added value.
Some options on how this could be handled:
- show a message in about:debugging#workers when "dom.ipc.multiOptOut" is true, with a button to re-enable multi e10s
- show a message in the console when "dom.ipc.multiOptOut" is true, with a link to about:config
- flip back the preference when closing about:debugging (or rather when closing the browser if possible, since the preference needs a restart)
ni? Marion to see how far the e10s-multi work is related here. If there is no reason for opt out, we should just flip the pref for users.
Flags: needinfo?(mdaly)
Version: 56 Branch → unspecified
We're targetting e10s SW for either 61 or 62. It may break things currently if the pref is flipped.
Flags: needinfo?(mdaly)
Can you clarify the causation: Do we expect breakage before or after e10s SW lands - and when users opt out of multi or do have multi enabled?
Flags: needinfo?(mdaly)
I'l let :asuth handle the technical details here.

As far as what we expect to break: We honestly aren't 100% sure yet, we're finishing up some work on remoting before we plan to flip on the pref for testing.
Flags: needinfo?(mdaly) → needinfo?(bugmail)
Right now, if there are N web content processes, there are potentially N instances of a given ServiceWorker.  The e10s-multi opt-out was introduced because this can result in confusing debugging scenarios of ServiceWorkers.  Especially since things like Push notifications will just pick the first web content process they find, which isn't necessarily where an already-existing SW is already running.

To restate: ServiceWorker-debugging and multi-e10s is currently a bad experience.  It will be a good experience when we land our ServiceWorker multi-e10s overhaul in 61 or 62 and flip some new secret prefs we are creating for testing.

In terms of this bug, the best suggestion I can make is:
- Have the button not only flip the opt-out pref, but also flip a pref or set a pref that indicates that the button was the source of the flip.
- When the SW multi-e10s overhaul lands, we can automatically flip the opt-out off again if it was that button that triggered the opt-out.
Flags: needinfo?(bugmail)
> To restate: ServiceWorker-debugging and multi-e10s is currently a bad experience.  It will be a good experience when we land our ServiceWorker multi-e10s overhaul in 61 or 62 and flip some new secret prefs we are creating for testing.

Given that the multi-e10s work is in progress I would like to block the new devtools panel on platform landing multi-e10s. We would otherwise risk to force more users to opt-in to non-multi-e10s just to use the new panel.

> - Have the button not only flip the opt-out pref, but also flip a pref or set a pref that indicates that the button was the source of the flip.
> - When the SW multi-e10s overhaul lands, we can automatically flip the opt-out off again if it was that button that triggered the opt-out.

We have existing users that switched multi-e10s off. If there are no other ways or reason to do this, we could just assume that the existence of a flipped pref for a user means that the user wanted to debug service workers and clicked the button.

Are there cases where this assumption would not be true?
(In reply to :Harald Kirschner :digitarald from comment #8)
> Given that the multi-e10s work is in progress I would like to block the new
> devtools panel on platform landing multi-e10s. We would otherwise risk to
> force more users to opt-in to non-multi-e10s just to use the new panel.

Makes sense.

> We have existing users that switched multi-e10s off. If there are no other
> ways or reason to do this, we could just assume that the existence of a
> flipped pref for a user means that the user wanted to debug service workers
> and clicked the button.
> 
> Are there cases where this assumption would not be true?

My concern is that boolean testing preferences that flip themselves off at every startup are frustrating.  I think it's appropriate to have some second stateful pref that ensures that the automatic preference flipping of "dom.ipc.multiOptOut" happens at most once without subsequent user action related to devtools.  For example, having a pref, "devtools.migratedPreferences.flipped-dom-ipc-multiOptOut" that gets set to true when the pref is flipped and only flips if this pref was not defined and "dom.ipc.multiOptOut" was set to true.  But the exact mechanism doesn't matter.
Ben Kelly brought up that multiOptOut is separate from the multi process preference that can be used to set the process count in Firefox performance preferences. AFAIK the multiOptOut pref was only used for the old SW debugging and is not needed going forward.

Question for Julian & Andrew (or others): Is it an acceptable option to just phase the pref out (remove support?) and just reset users – or are there concerns/risks that I am not aware of?
Flags: needinfo?(jdescottes)
Flags: needinfo?(bugmail)
It looks like we could just bump nsIXULRuntime.E10S_MULTI_EXPERIMENT to 2 at https://searchfox.org/mozilla-central/rev/49cc27555d5b7ed2eb06baf156693dd578daa06f/xpcom/system/nsIXULRuntime.idl#117

Then the logic at https://searchfox.org/mozilla-central/rev/49cc27555d5b7ed2eb06baf156693dd578daa06f/toolkit/xre/nsAppRunner.cpp#5217 will automatically start ignoring people who set the value to 1, but they still have a way to opt-out again if they want.  They just set the value to 2 to opt-out again in that manner.

Bug 1349363 seems to discuss the rationale for all that.

We could probably also remove the mechanism, but the mechanism does seem pretty nice in the event we ever need to push an emergency pref-change or system add-on to disable multi-e10s and don't want to mess with peoples dom.ipc.processCount.  I suggest raising the issue for discussion on dev-platform if you want to remove the pref entirely.
Flags: needinfo?(bugmail)
From my perspective there is no risk but I only know about the about:debugging end of this :(
The proposition from Andrew sounds reasonable and should cover our needs.
Flags: needinfo?(jdescottes)
Product: Firefox → DevTools
Just to add a voice here as a developer who has no need to debug service workers any longer and can't find a way to go back to e10s. Trying to find what was toggled when I clicked to opt out of e10s and how to opt back in is frustrating. I couldn't even figure out if e10s is enabled or not as `about:support` shows it as enabled but I can't see the UI we had to set process count on `about:preferences` or `about:performance` which used to list memory consumption per process.

If at least this opt out was better documented or if the link to the documentation was discovered more easily it would be better than the current experience which is a bit confusing.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.