What Mozilla’s browser rewrite means to… Mozilla
The problem with per-tab processes in Firefox is that it’s not exactly groundbreaking. In fact this is a case of Firefox just now catching up to where Chrome was when it launched in 2008 – welcome to the future, Mozilla.
Still, while it’s easy to make fun of Firefox for playing catch-up, Electrolysis was no small feat. Chrome had the advantage of being designed for process isolation from the ground up while Firefox had to work it into its existing code base.
The good news for Firefox users is that Electrolysis isn’t the only major change coming to Firefox this year. Despite these seemingly tumultuous times at Mozilla, Firefox engineers have outlined a plan to rewrite the engine behind Firefox.
The company calls this effort Project Quantum and, despite the name, it looks to be a major change for Firefox. Indeed, perhaps the biggest change since Firefox first launched.
The major goal is to create a new rendering engine that’s able to exploit the full power of today’s hardware, which is a kind of marketing speak for “we’re going to isolate every process and offload more rendering tasks to the GPU”.
A large portion of Quantum will be pulled from the existing Servo project, which is a low-level rewrite of Firefox’s Gecko rendering engine. Servo remains independent and covers a lot more ground (for example it provides an API for using Servo inside other projects and it’s been ported to Android by Samsung). Quantum takes what’s good about Servo – independent processes for all the things, the Rust programming language – and brings it to Firefox.
But that’s not all Quantum plans to do. Mozilla’s David Bryant, head of platform engineering, writes that Quantum will also see Mozilla going back to the drawing board to “rethink many fundamental aspects of how a browser engine works”. That means potentially “re-engineering foundational building blocks, like how we apply CSS styles, how we execute DOM operations, and how we render graphics to your screen”.
Right now, for example, any CSS file in the head of an HTML document must be downloaded and rendered before a page can be displayed. That slows down the rendering of pages, especially on sites that use poorly coded blogging tools that pile in style sheets like they’re delicious candy – I’m looking at you, WordPress plugin developers. They’re not candy, they’re a rendering nightmare.
But since it seems there’s just no way to stop the web-slowing world of crappy blogging tools, perhaps the browser can figure out a way around this by rethinking the rendering process. Perhaps not stopping for every stylesheet, but instead spinning off a new process for each stylesheet would help mitigate the problem (or we could all rediscover Lynx and w3m, problem solved).
In fact, this is already part of Servo and by extension Quantum. It’s one of the four core components of Quantum, which are Quantum CSS, Quantum Render, Quantum Compositor, and Quantum Flow.
Quantum Render is where Servo’s process isolation and GPU offloading come in and Quantum Compositor builds on Gecko’s existing compositor, but moves it to its own process (notice a running theme here?). The last bit is the least developed right now, but it will encompass other things like UI speed improvements.
If all this sounds like an overly large project that may never actually ship code, well, I share your concern.
Bryant’s article is from late 2016 and claims Mozilla is “going to ship major improvements next year,” though there is no specific date. In a recent post about Firefox’s new Web Assembly feature, Bryant says that “Project Quantum is well under way”.
In light of recent changes – and, frankly, what feels like disarray at Mozilla with the repositioning then killing of its phone-turned-TV operating system Firefox OS and developers cut – it’s tough to get too excited about anything. Still, Quantum looks promising and may be the thing Mozilla needs to get it back on track and provide a bit a focus. ®