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 to have more than one content 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.
- Technical overview
- A very high-level view of how multiprocess Firefox is implemented.
- A reference for the jargon used in multiprocess Firefox.
- Message manager
- Complete guide to the objects used to communicate between chrome and content.
- SDK-based add-ons
- How to migrate add-ons developed using the Add-on SDK.
- Which URIs load where
- A quick guide to which URIs - chrome:, about:, file:, resource: - are loaded into which process.
- 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 content processes
- How to debug code running in the content process, including frame and process 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.