Electrolysis

Goal

The goal of the project is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed (although sandboxing the content processes is a separate project from Electrolysis). Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.

Although the Gecko platform supports multiple processes, the Firefox frontend is not designed to use them. Work to make the frontend (including addons) support multiple processes was begun in early 2013. The project roadmap has more details.

Enabling Electrolysis

We're developing off of mozilla-central. Therefore, it's possible to enable Electrolysis right now in Firefox nightlies.

• Update to a current nightly.
• We strongly recommend you create a new profile!
• Set the browser.tabs.remote preference to true.
• Restart Firefox.

What to Expect

Basic browsing should work as expected. Tabs that are loaded remotely (i.e., in a separate process) will have their title underlined. By default, only one content process is used. You can control this with the dom.ipc.processCount preference.

What works:

• Back and forward buttons
• URL bar and search bar
• Context menu (somewhat)
• Middle clicking to open links
• Bookmarks
• Flash (sometimes)
• Add-on installation on a.m.o (without download progress)
• The find bar

What doesn't work yet:

• Session restore
• Developer tools
• Many addons
• Many plugins
• Click to play
• Zooming

Contributing

The simplest way to help out is to file bugs when you find them. The tracking bugs are fxe10s and core-e10s. We also have a master todo list in the wiki.

Most bugs in electrolysis occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via browser.contentWindow, browser.docShell, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect.

The ideal way to solve these problems is with the message manager. Any code that touches data in the content process should run in a content script. Content scripts communicate with chrome by message passing. Often, it's fairly easy to partition code into content and chrome portions and use message passing to communicate.

However, there are cases where it is awkward to partition code in this way. In these cases, it may be beneficial to use cross-process object wrappers (CPOWs). CPOWs make it easy to transparently access content objects from chrome. The main drawback of CPOWs is that they are slow and they cause the chrome process to block, which can lead to jank. However, there are times when it makes sense to use CPOWs. For example, CPOWs are used to generate the menu items for the Firefox content menu. Creating the content menu sends a small number of CPOW messages since it doesn't touch the content document very much. And while the main event loop will be blocked while generating the menu, users are unlikely to notice since they're just waiting for the menu to appear.

Communication

Weekly Team Meeting	Thursday at 2:30pm PT (5:30pm ET) for 30 mins Vidyo: William McCloskey's Video Room Invitation: Contact billm@mozilla.com to get added to the meeting invite list. Dial In Information: Meeting Notes Etherpad Historical Notes: Meeting Agendas and Notes We are currently looking into a time that could work for Australian eastern timezone.
IRC	Server: irc.mozilla.org Channel: #e10s
Tracking bugs	fxe10s for frontend bugs core-e10s for platform bugs
Newsgroup/Mailing List	https://lists.mozilla.org/listinfo/dev-tech-electrolysis
Project branch	We use the project branch only for experimental code. We don't recommend people test with it. Please use mozilla-central instead. https://hg.mozilla.org/projects/larch/ https://github.com/mozilla/mozilla-central/tree/larch

People

Project Champion	Vlad Vukicevic ( A )
High Level Oversight	Johnathan Nightingale ( I ) Gavin Sharp ( A )
Project Management	Chris Peterson ( R )
Development Team	Nicholas Alexander ( R ) David Anderson ( R ) Felipe Gomes (Firefox front-end) ( R ) Mark Hammond ( R ) William McCloskey ( R ) John Schoenick (plugins) ( R ) Tom Schuster ( R )
Other Teams	Accessibility: Alexander Surkov and Trevor Saunders (bug 646596) Addon Developer Relations: Jorge Villalobos Developer Tools: Dave Camp (bug 875871) IME: Makoto Kato (alternately, Masayuki Nakano) (bug 926798) Jetpack: Dave Townsend OMTC/Windows: Nick Cameron (bug 756608) Printing: Olli Pettay (bug 927188) Sandboxing: Brian Bondy, Sid Stamm (bug 925570) WebAudio: Ehsan Akhgari (WebAudio currently works on B2G, but Ehsan says he's not sure how the audio backend handles IPC.) WebRTC: Randell Jesup or Eric Rescorla. WebRtc is currently getting ready to go into B2G - mozGetUserMedia will be in 26/1.2, and PeerConnections will be in 28/1.3.

Here is what the letters following each name stand for, those higher on the list include all those below:

• R = Responsible for deliverable, in most cases this is anyone writing code.
• A = Accountable for the final decision making on some aspect of the project, often leadership that is not working on code but have go, no go decision making.
• C = Needs to be consulted on key topics, often this would be for subject mater experts that need to be consulted but don't have decision making power.
• I = Needs to be kept informed, those that just need regular status reports sent to them.

Reference

• The message manager

• Cross-process object wrappers

• Archive of past content on this page

• Electrolysis platform notes

• Notes on the Chromium IPC library

• Addon Compatibility Test Results

• IDL comments about Message Manager

• Tim Taubert's "Firefox Electrolysis 101" blog post (2011)

Meeting Notes

Create a new weekly agenda from the template: <createbox> align=left type=create preload=Electrolysis/Meetings/0-0-0 default=2025-06-26 prefix=Electrolysis/Meetings/ </createbox>