We'd like to give our beta population an opportunity to test out e10s as of 43.0. Beta 1 is ideal (GTB: Nov 2, Ships: Nov 4) but as this is fairly last-minute request, Beta 2 is also good (GTB: Nov 9, Ships: Nov 10). Other specifics: Opt-In = Yes Check Box = Yes Non-e10s Menu Item = No

Is there a bug for enabling e10s tests on beta? Right now, they're only enabled on Aurora and trunk.

Tracking so that I will keep an eye on this.

Is Beta 43 going to nag users to opt into e10s via a notification pop? Or will this just add the e10s opt-in pref to Options?

Note that if we do this, we probably won't ever get into a "green" state on overall Beta 43 stability and will not know if we'll be really good on release or not, as out crash rates by design cannot differentiate between people having e10s on or off (we use ADI and those do not know about that).

:kairo, we are working to address this in Bug 1218528. Please chime in that bug with any guidance/questions/suggestions.

(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #3) > Is Beta 43 going to nag users to opt into e10s via a notification pop? Or > will this just add the e10s opt-in pref to Options? :Felipe is going to post options for Product and UX to choose from. We're not blocking on fancy UX.

Here's the checkbox that we have in the Preferences window

And here's the popup dialog that we have that offers people to try to use e10s. And an infobar that shows up after they start using e10s for the first time (regardless if it was through the popup or the checkbox)

Things to decide: - use the doorhanger offer? Also we need to choose how many times it is displayed. We were very aggressive on Nightly/Aurora and the popup shows 5 times (i.e., on 5 start ups) until it gives up. But for beta it should probably be less annoying - display the yellow infobar that shows up once after restart? - The Learn More link/button that can be seen in the screenshot currently points to a wiki page, but it should point to something nicer for the beta population - Should we wait for Beta 2 to not mix non-e10s problems that might be reported with the uplift? And two notes: - e10s requires a restart to take effect. The current checkbox "forces" the use to restart, or reverts to non-e10s. This is to not confuse users about the state in which the browser is in (i.e., if the checkbox is checked but the browser hasn't restarted yet). - we currently add a " - e10s" to every tab title on e10s.. I'm guessing we don't want that for beta

Oh, and there's the target population: all users, or en-US only. It might make sense to limit it to en-US if we are expecting bug reports / direct feedback from users. Also as a way to filter this to not go to the entire beta population to get more stability testing for non-e10s.

As discussed in yesterday's channel meeting, IMHO, e10s is too immature stability-wise to be enabled even with opt-in on 43 Beta, and we have not run out of things we need to fix (adding another population IMHO only makes sense to find out if we find more issues we need to work on). Also I think that our beta population doesn't even understand what the opt-in really is for, no matter how we phrase it.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11) > As discussed in yesterday's channel meeting, IMHO, e10s is too immature > stability-wise What makes you say this? > to be enabled even with opt-in on 43 Beta, and we have not > run out of things we need to fix (adding another population IMHO only makes > sense to find out if we find more issues we need to work on). We're down to 39 bugs, most with patches. So, yes, we're running out of things to fix. > Also I think > that our beta population doesn't even understand what the opt-in really is > for, no matter how we phrase it. This is for Madhava to figure out.

Decision makers for the above are: :Madhava, :osunick, :Vladan.

this needs an assignee. We have ifdefing in code that might need tweaking / removal before we can turn things on for beta.

(In reply to Jim Mathies [:jimm] from comment #14) > this needs an assignee. We have ifdefing in code that might need tweaking / > removal before we can turn things on for beta. no need for an assingee since felipe already owns this. It should be tracked under an e10s milestone though. Felipe, releng would like to make sure test runs are working properly before they turn tests on in bug 1219342. Can we take test runs for a spin as part of this work?

[cc-ing Verdi for details] Early thoughts: - Doorhanger on a few browser startups (3 maybe?) asking for opt-in seems reasonable - not requiring an immediate restart (i.e. options to restart now or later) would be a better experience given that people will have _just_ restarted the browser when they updated - hanging the doorhanger off of the menu (hamburger) button is preferable to off of the left end of the url bar, given that a user goes into prefs (in the menu) to change this again later -- not a totally clear path of course, but that's likely a followup problem further things - would be great to talk about this in a way that might appeal to a broader audience - why should I want this now? Can we talk about responsiveness and stability? - if we don't think we're going to get enough attention on a doorhanger to hit whatever our opt-in targets are, what about some kind of in-content "what's new" page? Similar to when you open private browsing and get the "new! tracking protection!" page - with an opt-in right in the page?

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #12) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11) > > As discussed in yesterday's channel meeting, IMHO, e10s is too immature > > stability-wise > What makes you say this? Because our crash rates on Developer Edition are still ~1.5x of what they were when we defaulted e10s to off (but still had the opt-in working AFAIK) before the 43 cycle, and are still a bit more than that away from the target where we consider stability to be "green" on this channel. > > to be enabled even with opt-in on 43 Beta, and we have not > > run out of things we need to fix (adding another population IMHO only makes > > sense to find out if we find more issues we need to work on). > We're down to 39 bugs, most with patches. So, yes, we're running out of > things to fix. Then it sounds to me like the crashes found by crash-stats are not enough looked into and filed. And sorry, beta is so low in quality and stability recently that I rarely even get to look into Developer Edition.

To me opt-in on beta 43 seems the wrong approach. Sticking for the moment with optimistic goal of releasing 45 with e10s. Together with keeping 43 release good. The important aim should be to discover what has been overlooked by nightly/aurora testers so developers work on it while 45 is still nightly. Making beta default e10s on (with opt-out) for a short time is better that leaving it to later when 45 is no longer nightly. There won't be a goal of uplifting e10s crash fixes to beta 43. 43 also lacks adding comments when submitting content crashes. I have a theory (unproven) that crash counts go up just because it is so simple to click restore all crashes tabs multiple times. (+ A/B telemetry test on sample of beta users as well, good for measurement.)

The A/B stats part is being discussed over email and GDocs, so clearing my needinfo

So I think we have consensus that we should run A/B experiments on Beta 43 isntead. This will get us user testing of e10s in Beta and unbiased stats from A/B testing. Should we WONTFIX this bug?

:osunick has opted for a A/B telemetry experiment for Beta 43.0, instead. See Bug 1220198. You can refer to the information in this doc for details: https://docs.google.com/a/mozilla.com/document/d/1Uj2FAPCWtBhoJp-hkpBq1E3t_VCGTSuWkpruar2yr54/edit?usp=sharing I'm closing as Wontfix for now. Thank you felipe for digging in so quickly and I'll keep this ticket in mind should we decide on an opt-in in the future.

clearing the flag for osunick.

e10s in 2016 not good idea. Why not in beta? Google Chrome gained.

Multiprocess is possible to enabled in latest beta Firefox version 43. -Install Firefox 43 beta9 -Change or add settings: browser.tabs.remote.autostart;true browser.tabs.remote.autostart.1;false browser.tabs.remote.autostart.2;false Additionally add or change and you have smooth scrolling: layers.async-pan-zoom.enabled;true dom.w3c_pointer_events.enabled;true dom.w3c_touch_events.enabled;1 With this settings e10s is active in beta. Why is blocked in release candidate 43? It is ridiculous...