By Asa Dotzler and Brad Lassey
Electrolysis is the project name for Mozilla’s efforts to split Firefox into multiple processes to improve responsiveness, stability, and security. The first phase of this work was to split Firefox into a UI process and a content process.
This first phase of enabling our multi-process architecture is making its way to some of our Firefox 48 users starting this week. This is the biggest change we’ve ever made to Firefox, so we’re rolling it out slowly. For Firefox 48, we’re only enabling it for classes of users that our testing shows it works well for and to begin with, we’ll only enable it for 1% of those users so we can check on the stability and engagement data and make sure nothing new and bad is showing up. After that initial period, if all looks well, we’ll ramp up to 100% of those users, which will be about half of all Firefox 48 users.
If our Beta testing goes well, in Firefox 49 we will enable the multi-process architecture for users with a small set of add-ons that are known to work well with the multi-process architecture. In Firefox 50, again provided beta testing goes well, we plan to enable the multi-process architecture for users with add-ons that have either set a flag to say they are compatible or that were built with our new WebExtensions add-on API which is compatible by design. Eventually we will enable the multi-process architecture for all users and add-ons that are incompatible may no longer work. For this reason it is imperative that add-on authors update their add-ons to be compatible with the multi-process architecture.
Accessibility and touch screens
The next major multi-process update is scheduled for Firefox 51 when we’ll ship it to users with touchscreens, accessibility, and right to left browsers. That will conclude the first phase of our roll-out of the basic process separation that brings responsiveness to the Firefox UI, even when heavy pages are loading.
That’s not the end of our multi-process work. Not even close.
Multiple content processes
The second phase of this effort is to support multiple content processes. Where before we split content from UI so that pages loading wouldn’t slow down the UI, next up we’re splitting up the content processes so that one heavy page loading cannot slow down or hang pages loading in other tabs. This work is underway and should be available in the first half of 2017.
In parallel to work on multiple content processes, we’re also working on building a hardened sandbox for content processes. The goal for sandboxing is to restrict what access processes that host web content have to the browser and to the operating system. This will help secure Firefox against a range of potential exploits. If all goes well in testing, this work could see release this year.
The final piece of this multi-process work will be to isolate extensions into their own sandboxed processes. Similar to how isolating and sandboxing web pages can help improve performance and prevent security exploits, putting extensions into their own process will make sure that an extension doesn’t slow down the browser or web pages and will help to prevent some classes of attacks on Firefox that could happen through extensions. We’re still in the preliminary phase of this work.
This is a huge project that will take several more releases to complete but we’ve got a great foundation in place with the first phase shipping to end users now. We’ll build on that foundation to bring even more responsiveness and security to Firefox over the coming months without sacrificing the memory usage advantage we have over our competitors. Stay tuned to this and other Mozilla blogs for updates as the biggest architectural change in Firefox’s history rides the trains to release.