Closed Bug 1225498 Opened 10 years ago Closed 10 years ago

Force e10s on on Nightly (and devedition?)

Categories

(Core :: DOM: Content Processes, defect)

Product:
Core
Component:
DOM: Content Processes
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: benjamin, Assigned: Felipe)

Details

User Story

* Remove the "new non-e10s window" menu item
* Remove "e10s" from tab titles
* Remove the "Enable multiprocess Nightly" item in prefs
* Remove all browser.tabs.remote.autostart* prefs and stop honoring them
* Continue honoring the e10s accessibility pref
* Allow users to run non-e10s for testing either with an environment variable or a command-line launch flag
Many people on nightly have old e10s-optout prefs. Once the M8 blockers are all done, we should remove this option, because we need to focus our early testers on the e10s configuration. Before doing this, we should post warning to firefox-dev/dev-platform and collect blocker-feedback from the core community. Blassey, can you confirm that we should do this (and which channels)?
Flags: needinfo?(blassey.bugs)
When doing this please consider that we still need to test features with non-e10s as well. If we make it too hard to run non-e10s then we will end up with bustage when things merge to beta/release. In particular, I often need to test both e10s and non-e10s for service workers. Requiring an environment variable or separate command-line launch is going to make things very annoying.
And also please note that bugs like bug 1185674 make e10s a PITA to use but aren't currently marked m8 blockers as far as I can tell. But past that, Ben is right: it's very common for developers to need to test things in non-e10s during bug triage or development, so it would be good if we at least kept the "new non-e10s window" bit and some way to tell whether a given tab is e10s (having it say "non-e10s" on the non-e10s ones, say). We've had a number of instances of non-e10s only bustage that went undetected until beta because so many of our early testers _are_ in fact using e10s. We should in fact be encouraging developers more to test their changes in non-e10s mode (and hence be making it easier to do so).
(In reply to Boris Zbarsky [:bz] from comment #2) > And also please note that bugs like bug 1185674 make e10s a PITA to use but > aren't currently marked m8 blockers as far as I can tell. That bug is a P1 in the performance phase. We expect it to improve greatly when its two depenncies are resolved (1171708, 1177310), both of which are m8+ > But past that, Ben is right: it's very common for developers to need to test > things in non-e10s during bug triage or development, so it would be good if > we at least kept the "new non-e10s window" bit and some way to tell whether > a given tab is e10s (having it say "non-e10s" on the non-e10s ones, say). > We've had a number of instances of non-e10s only bustage that went > undetected until beta because so many of our early testers _are_ in fact > using e10s. We should in fact be encouraging developers more to test their > changes in non-e10s mode (and hence be making it easier to do so). Right, I do think its useful to have a small portion of our nightly audience on non-e10s until we are able to move our full release population over to e10s.
Flags: needinfo?(blassey.bugs)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.