Project Electrolysis: Bringing Multi-Process to Firefox

Project Electrolysis, commonly abbreviated as e10s, was Mozilla's monumental engineering initiative to transition the Firefox web browser from a legacy single-process architecture to a modern multi-process model. This article provides an overview of what Project Electrolysis was, why the old browser model failed to keep up with the modern web, and how splitting browser tasks into separate processes revolutionized Firefox's stability, performance, and security.

The Problem with a Single-Process Browser

For the first decade of its existence, Firefox ran entirely inside a single operating system process. This meant the browser's user interface (the tabs, toolbars, and menus) and the web pages you visited shared the exact same computing thread.

As websites evolved from static documents into complex applications heavy with JavaScript and media, this single-process model became a major bottleneck. It resulted in two critical flaws:

  • Browser Freezes: If a web page executed a heavy script, the main thread was blocked. The entire browser would become unresponsive, preventing you from scrolling, switching tabs, or even closing the offending tab until the script finished.
  • Total Crashes: If a single web page encountered a fatal error, it took the entire browser process down with it, crashing all open tabs simultaneously.

What was Project Electrolysis (e10s)?

Named after the chemical process of using electricity to split water into hydrogen and oxygen, Project Electrolysis was designed to split Firefox's monolithic structure into distinct, independent processes. In developer shorthand, the project became known as "e10s"—a numeronym standing for the letter "e", the ten letters in the middle of the word, and the final "s".

How e10s Changed Firefox's Architecture

To bring multi-process architecture to Firefox, e10s separated the browser into two primary types of processes that communicate with each other asynchronously:

  1. The Parent (UI) Process: Also known as the "chrome" process, this single process is strictly responsible for managing the browser's user interface, such as rendering tabs, the address bar, and bookmarks. It also handles system-level operations like network requests and disk access.
  2. The Child (Content) Processes: These processes are exclusively dedicated to loading and rendering web content, including parsing HTML, applying CSS, and executing JavaScript.
  3. Inter-Process Communication (IPC): Because the UI and the web content no longer lived in the same place, Mozilla built a fast message-passing system. This allowed the parent and child processes to share data without ever blocking or slowing each other down.

The Three Pillars of Multi-Process

By isolating web content from the core browser, Project Electrolysis delivered three immediate benefits to Firefox users:

  • Unmatched Stability: When a web page crashes under the e10s architecture, only the specific content process handling that page dies. The parent process remains unaffected. Instead of the whole browser closing, Firefox simply displays a "Gah. Your tab just crashed" screen, leaving all other tabs intact.
  • Fluid Responsiveness: Because the UI operates on its own dedicated thread, a frozen or infinitely looping script on a web page can no longer lock up the browser. Users can effortlessly switch tabs or close a hung page instantly.
  • Security Sandboxing: Multi-process architecture laid the groundwork for strict security sandboxing. Content processes are locked in a restricted environment where they are forbidden from directly accessing your computer's file system, memory, or hardware. Even if malicious website code exploits a content process, it is trapped inside the sandbox and must go through the heavily guarded parent process to do any real harm.

The Add-on Challenge and Rollout

While competing browsers like Google Chrome launched with multi-process architecture from day one, retrofitting it into Firefox was the largest change to Firefox's code in its history. The primary hurdle was Firefox's massive ecosystem of legacy add-ons. Traditional Firefox extensions had unrestricted, direct access to both the UI and web content, assuming everything existed in one process.

To prevent breaking thousands of extensions overnight, Mozilla engineered temporary compatibility layers called "shims" that allowed old add-ons to function across processes, though at a performance cost. Eventually, Mozilla used the e10s transition to phase out legacy extensions in favor of the modern, multi-process-friendly WebExtensions API.

Mozilla began the phased rollout of e10s in August 2016 with Firefox 48. Initially, it separated the browser into just two processes: one for the UI and one for all web content. By June 2017, with the release of Firefox 54, e10s expanded to use up to four separate content processes simultaneously. This successful transition completed the foundational architecture required for the critically acclaimed Firefox Quantum (Firefox 57) update in late 2017.