Closed Bug 1230238 Opened 4 years ago Closed 4 years ago

Please disable e10s in aurora

Categories

(Core :: General, defect)

44 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed
b2g-v2.5 --- fixed

People

(Reporter: ritu, Assigned: Felipe)

References

Details

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1203184 +++

Similar to what we did in FF42 cycle, we will disable e10s in Aurora44.
We need to disable it to get a better picture of 44 stability before it enters Beta cycle.
felipe, can we reland the patch in bug 1203184 on aurora for this?
Flags: needinfo?(felipc)
Assignee: nobody → felipc
Status: NEW → ASSIGNED
Flags: needinfo?(felipc)
Yeah, so there are two options:

1-) Disable e10s for users who got e10s enabled by default, while keeping users who opted-in through the doorhanger (bug 1161260).  Note: when we started trying e10s on aurora, approximately 50% of users opted-in. This is what we have done in the past, but this would disable it only for 50% of aurora users.

2-) Disable e10s for all aurora users.


Ritu, which one would you prefer?


Jim: if it's option 1, we can just reland bug 1203184.  If it's option 2, we can land the patch attached here (can you review it, if that's the case?).  Note: in both cases the patch should only land on aurora, not m-c.
Flags: needinfo?(rkothari)
Is the proposed patch (option 2) going to break the running of automated tests?

(option 1) Major crashes have been a11y enabled, possibly all of these need forcing off.

User opt-in is currently just below 20%. Will some users get the prompt to opt-in if default is disable?

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2015-12-01&keys=__none__!__none__!__none__&max_channel_version=aurora%252F44&measure=E10S_AUTOSTART_STATUS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2015-11-25&table=0&trim=1&use_submission_date=1
(In reply to Jonathan Howard from comment #4)
> Is the proposed patch (option 2) going to break the running of automated
> tests?

Looks like it might since e10sAllowed is absolute. A try push of the aurora branch can confirm this.

I think we should copy what we did last time since it was sufficient for release managers in 43 imo.

FYI felipe is traveling, he should be in orlando tonight. Not sure if he'll be checking bug mail though.
Hi Felipe, I am leaning towards option 1 because the idea of explicitly disobeying end-user e10s opt-in choice does not seem right, even for a week. 

So while option 2 would get us a much better picture of FF44 stability, I think we should go with option 1, as it seems like the right thing to do by our end-users.
Flags: needinfo?(rkothari)
Attachment #8696020 - Attachment is patch: true
Attachment #8696020 - Flags: approval-mozilla-aurora?
Comment on attachment 8696020 [details] [diff] [review]
disable opt-in

We are planning to disable e10s by default for the last week of Aurora44 to get a better picture of 44 stability before it enters beta cycle. Folks who have opted-in for e10s during Aurora44 will be unaffected by this. Let's uplift to aurora.
Attachment #8696020 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Jim landed:
https://hg.mozilla.org/releases/mozilla-aurora/rev/695a52aa5554

(In reply to Jonathan Howard from comment #4)
> User opt-in is currently just below 20%. Will some users get the prompt to
> opt-in if default is disable?

Jonathan made a really good point, so I landed a quick follow-up to prevent that:
https://hg.mozilla.org/releases/mozilla-aurora/rev/afefb6c948e6
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.