Mozilla Add-ons Community Blog
Firefox Logo on blue background
Categories: compatibility developers sdk webextensions

The “Why” of Electrolysis

18 responses

A multi-process architecture is finally coming to Firefox. Known by its codename, “Electrolysis” or “e10s,” this project aims to split the Firefox browser into a single process for the UI, and several processes for web content, media playback, plugins, etc.

Electrolysis represents a long overdue modernization of Firefox’s codebase: Internet Explorer has been multi-process since IE 8 Beta 1 in early 2008, Chrome followed six months later, and even Safari went multi-process in the summer of 2011. Put another way, Firefox has been the only major browser using a single process architecture for the past five years.

Benefits for Users

Though the result should be visually indistinguishable from a single-process Firefox, the multi-process model offers many compelling advantages in responsiveness, stability, performance, and security:

  • Responsiveness. By placing web content into a separate process from the browser interface, we can ensure that Firefox’s UI stays snappy even when a page is doing heavy computation or undergoing garbage collection.
  • Stability. Tabs shouldn’t crash, but when they do, isolating web content in separate processes means they can crash without taking down the rest of the browser.
  • Performance. A multi-process architecture lets us spread work across the many CPU cores present in modern computers and smartphones, resulting in more efficient utilization of the underlying hardware.
  • Security. Process separation makes it easier to implement restrictive security sandboxes for web content.

A common concern is that switching to a multi-processes architecture will dramatically increase Firefox’s memory usage. This is not the case. While multiple processes will have a greater memory footprint than a single process, the impact should be limited: we’re currently seeing multi-process Firefox use 10-20% more memory, however, it still uses half the memory of Chrome with the same sites loaded.

To ensure we don’t consume too much RAM, the first release of e10s will only use a single additional process for web content. We’ll add more processes in subsequent releases, as we become more memory efficient.

Challenges for Add-on Developers

The move to multi-process is an investment in the future: we’re paying down technical debt and redesigning Firefox’s architecture at a fundamental level. Like any change of this magnitude, there are associated challenges:

1. Cross-Process Communication. Before e10s, add-ons were accustomed to having direct access to both the browser context and web page content. With e10s, those two contexts are now two separate processes which must communicate through asynchronous message passing.

Many, but not all, add-ons will require modification to work efficiently with this new design. Add-ons that do not access web content, only use high-level SDK APIs, or are written with the new WebExtension APIs will not need modification.

You can see the compatibility status of popular add-ons at AreWeE10SYet.com, or use the compatibility checker to see what changes your add-on might need.

2. Performance. To help with compatibility during the transition to multi-process, we’ve implemented several temporary shims that allow backwards-compatible, synchronous communication between the browser and web content. This lets add-ons work as if Firefox was still single-process, but with potentially worse performance than before, since these shims must completely block multiple processes and incur overhead for inter-process communication.

The shims are available to add-ons by default, but authors should always prefer asynchronous message passing, high-level SDK APIs, or WebExtensions instead of shims.

You can disable shims for your add-on by setting the multiprocess permission to true in your package.json, or set <em:multiprocessCompatible> to true in your install.rdf. This is how we know your add-on is e10s-compatible and will ensure that it won’t be marked as incompatible when e10s ships with Firefox.

Try it Today

Multi-process has been enabled by default in Firefox Developer Edition since version 42, released last August. If you’re an add-on developer or Firefox enthusiast, we highly recommend you try it out and report any bugs you encounter, either in Bugzilla or in the comments below. The Mozilla Developer Network also hosts extensive documentation on multi-process Firefox, including migration guides for add-on authors. Check it out, and let us know what you think!

18 comments on “The “Why” of Electrolysis”

  1. JustOff wrote on

    In other words, the next round of Firefox ecosystem destruction is finally coming.

    1. Dan Callahan wrote on

      As in forestry, sometimes a bit of controlled burning is necessary to spur new growth and ensure the long-term health of the ecosystem.

      1. JustOff wrote on

        All generalizations are false, including this one. Simple let’s see how many addons will remain alive, when CPOWs will be strictly disabled, on the background of motivation absence, because of announced refusal of XUL/XPCOM.

    2. daiquiri wrote on

      hey look mom, another hater who doesn’t like any change at all, even when it’s good!

      1. Max wrote on

        It’s not hate when it’s based on experience.
        Mozilla has been down this road before.

    3. Jens wrote on

      As a user I am really looking forward to e10s I think the pros outweigh the cons by far. OTOH, I still hope that my favorite add-ons like the rss brief etc. will make the shift towards the new architecture.

      After all https://www.arewee10syet.com/ does not look too bad, but still lots of work required :-/

      1. JustOff wrote on

        Unfortunately can’t share your optimism as a dev.

    4. Trond Nyland wrote on

      Finally we got the Firefox ecosystem running, Thanks
      Trond Nyland

  2. Tom Queen wrote on

    What a ridiculous idea!!
    This will make this browser (Like Chrome, Opera, etc.) nothing but a memory hog!
    The browser functions very well as a single process browser right now!
    How can you think that Multi-process wil improve the browser in ANY way?

    1. Dan Callahan wrote on

      Hi Tom,

      You’ll find exact measurements of the memory impact in the paragraph beginning “a common concern is that switching to a multi-processes architecture will dramatically increase Firefox’s memory usage.” Follow the two links in that paragraph for even more detail.

      Similarly, the specific answers to how we think this will improve Firefox can be found in the bulleted list under the large “Benefits for Users” heading.

      Happy to help,
      -Dan

    2. wheany wrote on

      I get almost daily crashes or weird behavior because Firefox goes over 2 gigs of memory (according to “private bytes” in process explorer). I have plenty of ram to spare, but firefox just won’t use it even when it clearly needs it.

      I’m hoping the separate processes will allow it to a) use less ram per process (even if it means more ram total), so it’s not as prone to crashing. And b) allowing a single tab (or a set of tabs) to crash and recover without bringing down all tabs.

  3. J. McNair wrote on

    Let’s be reasonable about this, folks. While Mozilla is aggressively reminding everyone of the eventual upsides of Web Extensions, they are not pretending that it’s free candy. Perhaps some at Mozilla are exhausted of hearing the same complaints, even if they are reasonable. But it’s wrong to say that Mozilla is ignoring its users. I argue that they are thinking of us more than ever.

    So far, Mozilla devs appear to be keeping all their promises to provide documentation, guidance and support for add-on developers. They also appear to be open to extending WebExtensions with features that aren’t possible in other browsers, specifically to enable the advanced add-ons that Firefox is known for. But it doesn’t change the fact that the transition will be painful. Some add-ons may even be lost forever, but delivering multiple process Firefox (a.k.a. e10s) to stable users is completely worth it.

    E10s actually began with Firefox 3.6.4, which enabled plugins to run in a separate process and vastly increased the reliability of the plugin-heavy web of 2010. Over the past 5 years, Mozilla developers implemented multiple processes for the rest of the browser and discovered that e10s improved the user experience. Sadly, they also found no way to keep existing add-ons from breaking things under e10s. Mozilla wisely decided that the improvements were too important to keep delaying e10s any further and Mr. Callahan already explained why.

    The solution was to come up with a new way for making add-ons. In a perfect world, the Add-On SDK (Jetpack) would have been fleshed out to accomplish this, but that didn’t happen, so they came up with a shortcut: WebExtensions. Because it’s a fork of Chrome’s extension API, it is well understood, PROVEN to work in a multi-process browser, and tested by millions. Furthermore, developers of (most) Chrome extensions can easily port them to Firefox, potentially bringing thousands of new add-ons and simultaneously improving its competitive potential. New add-ons that are (almost) guaranteed to work with a safer and faster Firefox are a net win for users.

    To conclude, Mozilla made the best decision it could, WITH THE TIME IT HAS, to deliver a browser we can use and love for YEARS down the line. This is painful, but highly rational. In fact, it’s so rational that Microsoft is doing something very similar with Edge, for similar reasons, which they hope will result in a browser that users will love for YEARS down the line.

  4. Noitidart wrote on

    Updating my addons to e10s was absolutely worth it! The only thing is we can’t transfer large pieces of data (large ArrayBuffer’s) between contents, as they are separate processes.

  5. Raymond Hill wrote on

    I see that my add-on, uBlock Origin, has been added recently to the list at “arewee10syet.com”, and is marked as “shimmed”. No issue number is provided.

    I am not aware of any issue of uBlock Origin not being fully compatible with e10s. Is it possible to find out why uBlock Origin was added to the list, and marked as not fully compatible?

    1. Jorge Villalobos wrote on

      It’s possible it was added as “shimmed” by default. I see that your add-on uses the right flags, so I updated the document that is used to feed that page. It should appear with the right status soon.

      1. Raymond Hill wrote on

        Thanks, I got worried there was something broken with uBO on e10s.

  6. Ivan Dejanovic wrote on

    Is there a timetable for when will electrolysis be shipped in release version of Firefox. One noticeable difference between Chrome and Firefox on Windows 10 that I use at work, at home I am on Ubuntu, is how faster Chrome is when more tabs are open. Especially if I open Slack. Personally I am OK with Firefox using more memory if that makes it faster.

    1. Dan Callahan wrote on

      It’s hard to say exactly. We’ll be rolling it out progressively over several releases, and in batches. E.g., we’ll likely turn it on first for half of all users without any add-ons installed, just to make sure we’re not causing any regressions. For now, I’d suggest trying out Firefox Developer Edition, which uses a separate profile and has e10s enabled by default.