With so many potential points of failure, it’s up to the browser makers to ensure that everything runs smoothly and securely. One way of doing this is by splitting the browser process into several components and isolating them from each other. This ensures that if one of them fails, it doesn’t bring down the entire browser. For example, if a site has buggy or malicious code, it may crash a tab, but it won’t affect the others or the browser as a whole.
The idea of multi-process tabs has been adopted by most browser makers and it’s starting to become the norm. Spearheaded by Google Chrome and Microsoft’s Internet Explorer 8, the concept has made its way into Mozilla Firefox and may soon be implemented in many of the WebKit-based web browsers, like Apple Safari. But, while the idea and the concept may be similar, the implementations differ from browser to browser.
Google Chrome/Chromium’s Multi-process ArchitectureGoogle Chrome was one of the first browsers to have multiple processes. It also has one of the most complex systems isolating many of the components from each other. There are four main process types in Google Chrome and Chromium:
- browser process - handles the user interface and manages all the other processes, which run ‘on top of it;’
- render processes - these handle the rendering in the individual browser tabs; it must be noted that one render process can handle more than one tab;
- plugin processes - each browser plugin, stuff like Adobe Flash or Java, is run in its own separate process; these processes communicate with the render process they are spawned from;
- extension processes - extensions also get their individual processes to keep them from interfering with the browser or with each other.
Microsoft Internet Explorer 8 Loosely-Coupled IE (LCIE)Microsoft took a surprisingly similar approach with Internet Explorer 8. With the so-called Loosely-Coupled IE (LCIE) architecture, IE 8 also splits the main browsing process from the rendering processes. The main process handles the browser, the UI and the frames (windows), which house the tabs. Several tabs are then run inside the same process, but tabs with different security levels are separated. ActiveX controls are handled by the tab processes.
Mozilla Electrolysis and Out-of-process PluginsMozilla has come late to the game, but Firefox has very recently gotten some multi-process capabilities. They are nowhere near as complex as Chrome or IE’s and, for now, aim just to separate the browser plugins from the main process. The project, codenamed Electrolysis, is in the early stages, but the first benefits are starting to be seen. The capability is now available in the latest Firefox 3.6.4 beta builds. There is some intention to extend the multi-process functionality to the tabs, but there are few clear plans for now.
Multi-process in WebKit 2Things are about to become even more interesting as the team behind WebKit, the web rendering engine powering a big number of browsers, has announced that it is building multi-process capabilities right into the renderer in the upcoming WebKit 2. Even though WebKit is used on Google Chrome/Chromium, the approaches are different. Where Chrome runs a WebKit instance for each of the render processes, in WebKit2, the rendering engine itself is split into multiple processes.
There will be a base WebKit UI process to house the application logic and a second process, dubbed the Web Process, will handle the actual rendering. The multi-process features will be independent of the application, which incorporates WebKit, the major difference from the Chrome model. This will enable developers to quickly and easily build multi-process features into their apps without modifying or adding too much code to them.