Mozilla making progress with Firefox’s long journey to multiprocess

Over the last year, the browser has taken steps toward being more stable and secure.

Multiple Firefox processes.

Internet Explorer and Chrome both use a multiprocess architecture to enhance stability and security. They separate the task of parsing and rendering Web pages from the job of drawing the browser on-screen, saving downloaded files, creating network connections, and so on. This allows them to run the dangerous parts—the parts exposed to malicious scripts and exploitative HTML—in a sandbox with reduced permissions, making it harder for browser flaws to be turned into system compromises.
 
It also means that they're much more tolerant of crash bugs; a bug will bring down an individual tab, but shouldn't, in general, bring down the browser as a whole.
 
In 2009, Mozilla announced the Electrolysis project, which was to bring this kind of multiprocess design to Firefox.
 
It's now late 2013, and Firefox still isn't a multiprocess browser. It does have a limited multiprocess design, as it can run plugins in their own process, but everything else is run in a single process, running with the full permissions of the user. The full Electrolysis project was put on hold just over two years ago.
 
Work on Electrolysis resumed in January this year, and Mozilla developers have started to talk about it in detail. Nightly builds of Firefox can now be used with multiple processes. Currently, this is still quite limited when compared to Internet Explorer and Chrome. Where those browsers will create a whole bunch of processes (generally around one per tab), Firefox Nightly creates two: one for the browser window and chrome itself, another for all the tab content.
 
The organization still has a lot of work to do before multiprocess support is ready for prime time. While basic browsing and some add-ons work already, others don't. The Firefox developer tools, for example, are non-functional.
 
Substantial work has been done to make Firefox work with multiple processes. In single process Firefox, add-ins and the browser user interface itself can directly access the page structure. With multiple processes, that's no longer possible: the add-ins and user interface exist in one process, the page structure in a separate one. Every such access has to be passed through a message-passing interface that connects the two processes.
 
To ensure that the user interface doesn't hang and remains responsive, those messages are asynchronous—the message sender doesn't wait for the message to actually be received. The result is a design that can be quite a bit more complicated than in single-process Firefox.
 
This message-passing mechanism has been in place since Firefox 4. Add-ins that use it should be in a good position to work with multi-process Firefox. However, not all do, because at the moment, they don't have to. In the meantime, some kind of fallback solution will have to be devised. Firefox has a second system for passing information synchronously between processes which can fill some of the gaps, but ultimately some add-ons may force the use of a single-process browser.
 
Mozilla has also had to change the way content is actually drawn. In traditional single-process Firefox (and, indeed, most software), a single thread is used to handle input events (like mouse clicks, keyboard clicks, and so on), calculate the layout and appearance of the screen, and then submit it to the operating system/GPU to actually draw. In doing so, the different elements of the page (backgrounds, fixed position items, videos, text) are all drawn onto separate layers. The GPU then flattens the layers together to create a composite image.
 
As part of the work done for Firefox OS, this was split into several threads. The main thread still responds to input events and produces the layers, but the work of moving the layers to the GPU and forming the final composite is done on a separate thread.
 
Multi-process Firefox builds on this work. It extends this split approach to all operating systems (not just Firefox OS), and the new approach is now the default on OS X (though not Windows or Linux). In multi-process Firefox, the content process creates the layers. These are then passed back to the main browser process, which sends them to the GPU and composites them.
 
There's no ETA yet for when Electrolysis will be moved to the stable branch of Firefox or turned on by default. Even when the basic development is complete, ensuring that add-ons remain compatible means that it's a complex project with hard problems to solve. Nonetheless, it's good that this progress is being made. When it's finished, it should make Firefox a much more robust, secure browser, and that's a change we should all welcome.
 
~  Peter Bright

Related Posts