Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect every browser tab to run in its own process. The project that's delivering multiprocess Firefox is called Electrolysis, sometimes abbreviated to e10s.
Normal web pages are unaffected by multiprocess Firefox. People working on Firefox itself and Firefox add-on developers will be affected if their code relies on being able to access web content directly.
Multiprocess Firefox is currently enabled by default in Nightly builds. As a visual indicator that you're running multiprocess Firefox, the titles of remote tabs are underlined.
- Technical overview
- A very high-level view of how multiprocess Firefox is implemented.
- A reference for the jargon used in multiprocess Firefox.
- The message manager
- How to communicate between chrome and content.
- Message Manager interfaces
- Includes links to the API reference for the message manager interfaces.
- Frame script environment
- The environment frame scripts run in, and especially how it differs from the environment for chrome code.
- Why we're implementing multiprocess Firefox: performance, security, and stability.
- Add-on migration guide
- If you're an add-on developer, find out if you're affected and how to update your code.
- Cross Process Object Wrappers
- Cross Process Object Wrappers are a migration aid, giving chrome code synchronous access to content.
- Debugging frame scripts
- Using the Browser Content Toolbox to debug frame scripts.
- Limitations of chrome scripts
- Practices that will no longer work in chrome code, and how to fix them.
- Limitations of frame scripts
- Practices that will not work inside frame scripts, and what to do instead.
Find out more about the project, get involved, or ask us your questions.