Posted by: felipe | July 20, 2011

Initial electrolysis patches for desktop Firefox now in mozilla-central

The last remaining patch to get Firefox to open and stand up with electrolysis enabled was landed late last week, and, after a few days baking, it has stuck! This means that anyone with a mozilla-central tree can now compile and test Firefox with the content running in a separated process, and start trying your own features and see how well they work or not (or if you can even get to them in the first place). To do this you just need to add one extra configure flag to your mozconfig:

ac_add_options ‐‐enable-e10s-compat

You’re now wondering why this is a compile-time flag and not a simple pref. This flag doesn’t do a whole lot, it mainly switches the main pref browser.tabs.remote to true, but it also switches off hardware acceleration and disables some code that partially break the UI with the pref on. The goal is to get rid of the flag relatively soon (and only use the pref), but for now it’s the easiest way to make sure everyone can focus on the important bits rather than having broken pieces getting in the way.

Things to know after you get the build

The first tab of each window is not remote. All the other tabs that you open are. Progress indicators, favicons, session history and titles don’t work yet (session history and titles are coming soon). Most input like mouse, mouse scroll, keyboard and focus works (although there are corner cases not covered yet). Ah, do not use it with your main profile! Results are unknown.

The content is hosted by the plugin-container process. You should be able to kill it and the content from the remote tabs will disappear (when Firefox is re-rendered, usually when you re-focus the window). You can then open new tabs and the process is recreated just fine.

With these patches in mozilla-central the goal is to make sure everyone can see the progress and test their new features with electrolysis on, and as importantly, do not break what currently already works.

The front-end tasks are being tracked by bug 653064, and platform bugs marked with [e10s] in the whiteboard. Those lists are in no way comprehensive, so do file bugs or ask around with important things that you notice are not tracked yet.

If you want to know more about the patches

On the platform side, the patches that landed added support to input events and were done in bug 583976. nsEventStateManager and nsFocusManager were made aware of the content separation, and when input/focus events are targeted at the content area (i.e. the <browser> element), they’re automatically forwarded (asynchronously) to the content process. On the front-end side, some code was changed to not assume that the content docShell exists, and messages are passed through the message manager when appropriate (e.g. loadURI). I’ll talk more about these details in other posts.

Next steps

Now that these base patches are in the tree, on the front-end side we’re working on making sure more operations work with electrolysis. Drew has got a neat logging for forbidden chrome->content operations in bug 666713, and the goal is to reduce as much as possible these warning for basic navigation tasks in Firefox, so that the noise can be reduced and we can tackle more features more efficiently. I’ve got more code ready (and some already reviewed) but which I can’t land right now because they’re triggering other [un-]related bugs. I’m already filing these bugs and asking around about them but expect me to start pinging more frequently to ask for help in figuring out and fixing bugs on broader areas of the code.



  1. Great to see this happening. I tried it now, and while there are the problems you mentioned, it is possible to some content render. Very exciting!

    A lot of basic stuff like window titles is already working in Fennec frontend code. Perhaps there are some ways we can share more code to help desktop finish that stuff faster?

    • Hi Alon, in fact we’re reusing a lot of the code (and knowledge) from Fennec whenever possible. See bugs 662008 and 663040 as examples. But I’m always looking for more places where it makes sense to share code.

  2. Why is the content being hosted by the plugin-container.exe process? Is that going to change in the long run?

    • Just because that’s how our child process happens to be named at the moment. Originally it was named mozilla-runtime but it was changed to make it clear at the time that it was hosting plugins, but it can also host web content and jetpack addons. It might be changed again, I don’t know. but that’s all that there’s to it

      • So there will only ever be two processes? I thought there would be a plugin-container process and a process for each separate tab, or at least a content process and a separate plugin process.

        I have no technical reason for expecting this, it’s just what I thought would happen 🙂

      • There will be various, we can launch more than 1 process of the same type. This already happens for plugins: each plugin type runs in a separate process (try opening flash and silverlight and notice that you have two plugin-container running)

      • @pd
        As I understand it, there will eventually be multiple processes for content, but how we choose what gets its own process has not yet been decided.
        Chrome uses a sort of hybrid “Process per site instance” model as a per tab model could be way to expensive on memory.

        You can see the different process models Chrome supports here:
        This may help the e10s team think through what approach Firefox should use.

  3. Very exciting stuff! After all this time, it’s nice to see this progress on e10s, keep up with the good work Felipe and the frontend team!

    Cheers from homeland! =)

  4. I think for branding reasons, it would be a bad idea to rename “plugin-container” to something else. I think it should stay for Flash and Silverlight etc., but the rest can be “firefox” or core/main can be “firefox-core” for example. For people who can work it out/heard from somewhere, they will then be able to kill a tab or set of tabs by killing a “firefox” process instead of accidentally killing the whole browser if they don’t need to. This is a super niche case, because you would only use the Task Manager/Activity Monitor if you can’t use an in-built one.

    At the moment, Electrolysis encompasses the same goals as WebKit2 – doing original research to separate tabs (content) from [core (chrome) & UI]. Later will be process-per-domain. Chrome’s model process-per-domain but still will share processes across domains as well, so there can be security problems that would still happen but be more difficult to achieve if Chrome’s model *really was* process-per-domain.

    By the way, Firefox 4 came with per-compartment** garbage collection (it also isolates websites into their own area so a flaw has to be exploited for domains to talk to each other).
    ** = a compartment is sort of a subprocess (if that’s a technical name, then correct me if I’m wrong), basically area of memory inside the process.

    • Cheers on the idea! That would be great 🙂


%d bloggers like this: