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
