Firefox 48 Beta, Release, and E10S

Tomorrow In the next few days, Firefox 48 Beta becomes available. If all goes well in our beta testing, we’re about 6 weeks away from shipping the first phase of E10S to Firefox release users with the launch of Firefox 48 on August 2nd.

E10S is short for “Electrolysis”. Similar to how chemists can use the technique called electrolysis to split water into hydrogen and oxygen, we’re using project Electrolysis to split Firefox into a UI process and a content process. Splitting UI from content means that when a web page is devouring your computer’s processor,  your tabs and buttons and menus won’t lock up too.

E10S has been enabled for some portion of our Beta audience since December of 2015 and we’ve had it enabled for half of our Beta population for the last 6 weeks. The team has been comparing the half with E10S to the half without for things like stability, responsiveness, memory usage, and more. And so far, so good. We’ve met all of our release criteria and assuming nothing shows up in Beta 48, we should be good to go.

(When we hit release in about six weeks, not all of our Firefox 48 users will get E10S. The teams have been working really hard but we’ve still got some compatibility and other work to do to make E10S ready for everyone. The groups that will have to wait a bit for E10S account for about half of our release users and include Windows XP users, users with screen readers, RTL users, and the largest group, extension users.)

This is a huge change for Firefox, the largest we’ve ever shipped. But don’t worry. The Electrolysis team at Mozilla has a release roll-out plan that ensures we’re going slowly, measuring as we go and that we can throttle up as well as down depending on what we see.

Here’s what that looks like. When we launch Firefox 48, approximately 1% of eligible Firefox users will get updated to E10S immediately. The 1% of release users should get us up to a population similar to what we have in Beta so we’ll be able compare the two. About ten days after launch, we’ll get another round of feedback and analysis related to the release users with and without E10S. Assuming all is well, we’ll turn the knobs so that the rest of the eligible Firefox users get updated to E10S over the following weeks. If we run into issues, we can slow the roll-out, pause it, or even disable E10S for those who got it. We have all the knobs.

As noted earlier, this is just the first phase. Next up we’ll be working to get E10S to the cohorts not eligible in Firefox 48. We want 100% of our release users to benefit from this massive improvement. After that, we’ll be working on support for multiple content processes. With that foundation in place, the next projects are sandboxing for security, and isolating extensions into their own processes.

It’s an exciting time at Mozilla. E10S is the largest change we’ve ever made to Firefox and we hope you’ll help us get through this with as few surprises as possible. To help out, get on Beta and let us know what you find.

update: There is some confusion about what’s new here. I think I can clear that up. E10S has been in beta for some time. That’s not new. It was there for half of our beta users for the entire previous 6-weeks cycle. What’s new here is that we’ve just recently met all of our release criteria and we think we can take the feature from beta to release in the next 6 weeks. Now we’re down to one final cycle — assuming we don’t encounter any surprises. That’s where you all come in. Please help us test this upcoming Firefox 48 beta well so we have confidence when we get to the end of the beta cycle that E10S works well for everyone that gets it. Thanks.

94 thoughts on “Firefox 48 Beta, Release, and E10S

  1. I’m concerned that Electrolysis is being shipped while regressions reported against it have no sign of being remedied.

    For instance the right-click menu on Linux is broken (and requires, once you’ve found the workaround) an awkward clicking-twice to activate a menu item. The bug was reported over 1½ years ago and has priority P1, but no sign of anybody being interested in fixing it: https://bugzilla.mozilla.org/show_bug.cgi?id=1106389

    And userContent.css simply doesn’t work, reported almost 2 years ago, with a comment that the plan is to fix it. Again it’s now P1, but stuck waiting decision on a suggestion instead of fixing it to completely remove userContent.css support! https://bugzilla.mozilla.org/show_bug.cgi?id=1046166

    I’m a Developer Edition user and these bugs were sufficient for me to disable Electrolysis pending their being fixed — so I still have it disabled. Are fixing these bugs (and presumably other regressions that I happen not to have encountered) deemed blockers before automatically enabling Electrolysis on those affected by them?

  2. > Splitting UI from content means that when a web page is devouring your computer’s processor, your tabs and buttons and menus won’t lock up too.

    The same could be achieved by moving UI to a different thread. This is not an excuse for separating UI and content into different processes.

    1. But splitting it into different processes is needed for sandboxing. And by writing “This is not an excuse for…” you seem to suggest that using multiple processes was easier than using multiple threads. The exact opposite is true.

      1. I meant that the problem of content devouring CPU and thus locking UI you described is not a valid reason to implement e10s, because it can be solved easier with multithreading instead multiprocessing. There are some benefits which multiprocess architecture can bring, but only if each tab will have its own, sandboxed and isolated content process. And, as far I read on Mozilla pages, this is not the case of Firefox, as you plan all tabs to share single content process.

    2. Security is the reason. They’re sandboxing the two. Still a much weaker alernative to Chrome’s and Edge’s per-tab sandboxing, though.

      1. Are you sure? I’d imagine that all of Chrome’s content tabs use the same sandbox profile, anyway. Or were you referring to a threat model where one malicious page would attack a different page?

    1. Yes Firefox predates Chrome by 6 years and had an already established framework that was not easily compatible with multiprocess.

    2. No, not the same. Chrome and Edge do per-tab sandboxing. So Firefox will continue to remain less secure.

      However, I notice this move also pisses off a lot of users because it may kill some of their favorite addons or it will increase the RAM consumption slightly.

      I think those users are DEAD WRONG and shouldn’t be listened to. However, I don’t think that would make the criticism go away, which is why Mozilla should’ve done what Microsoft did and create a new browser from scratch, written in Rust, that has all the sandboxing and security features it wants, without having to care about supporting any legacy code or add-ons at all.

      I think Mozilla is going about this the wrong way, and they’ve already wasted many years trying to backport weak partial sandboxing onto a crumbling platform. The effort would’ve been better spent creating a lighter, more secure browser.

        1. I know about Servo. I meant a whole new browser should be created from scratch, not just the rendering engine.

      1. While writing a new browser from scratch would be interesting, I don’t think Mozilla has the manpower to do that and maintain Firefox at the same time.

      2. Well… yeah

        One step at a time man. Rust has only been out of beta for a year. Servo still usually unstable features.

        I want a futuristic fast safe browser yesterday too. But Mozilla has a lot more work ahead of them.

  3. I am using Firefox Dev Edition with Electrolysis enabled from many months and it looks almost stable now. I dont know if anyone noticed this but the CPU and memory usage reduced drastically with increasing number of tabs (I have about 40 open tabs) with e10 enabled. And with this, Firefox uses lot less resources than Chrome on my system with multiple tabs.

Comments are closed.