TB, Electrolysis & Quantum

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Wed Dec 28 22:11:54 UTC 2016


On 12/22/2016 11:56 AM, Disaster Master wrote:
> Hi all,
>
> First, I was just reading an article on the new multi-process 
> capabilities of Firefox vis a vis Electrolysis. Can anyone speak to 
> the relationship of Electrolysis to TB? I'm guessing there is none 
> (meaning, TB will never benefit from Electrolysis)?

The benefits of multiprocess are greatly oversold--in terms of security, 
it's basically the equivalent of setting up a cubicle wall: it will stop 
a few half-hearted passive attacks, but any serious code execution 
attack pretty much has full access to your machine anyways. Its biggest 
benefit is stability, which is to say, letting Flash crash and burn 
without killing Firefox--and that portion was implemented all the way 
back in 3.6 (not without controversy). If you hadn't noticed, it's taken 
several years for the developers to get around to actually shipping 
out-of-process for web content (which has been possible in theory since 
about Firefox 4 or so).

It's hard to see much benefit for multiprocess in TB, especially given 
that HTML email tends to avoid features that truly stress the backend.
>
> Then I encountered an article about Firefox's upcoming replacement for 
> Gecko, named Quantum, that, according to David Bryan, Head of Platform 
> Engineering at Mozilla, is supposed to "start delivering major 
> improvements to users by the end of 2017".
>
> https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12
>
> This was very interesting to me since I've never heard of Quantum. I 
> had read about what I thought was another new engine being developed 
> by Mozilla called Servo some time ago, but it had sounded like it was 
> a long way off, and a little googling reveals that Quantum is 
> apparently the official name of the new engine which is written (I 
> think) in Rust, and uses the 'high performance components of Servo', 
> so I guess 'Servo' is just the 'tech' behind it? Also, the expectation 
> of Quantum being implemented *this year* is significant news (to me at 
> least) too.
>
> https://wiki.mozilla.org/Quantum
>
> This is a little confusing to me, so if I messed any of that up, 
> please correct me.

This feels like a layer of marketing blather combined with a pitch for 
new contributors that's hiding what's really going on. If you read 
McCloskey's blog post, you do get a better sense of what Quantum is. 
Basically, they're trying to make rendering more multithreaded. It looks 
like there's also an attempt to replace the CSS engine of Gecko (roughly 
the layout/ folder) with Servo's CSS engine. This seems somewhat sketchy 
to me, given that the Firefox frontend still uses XUL and XBL 
heavily--although looking at the bug list, one of the blocking bugs is 
"implement XBL <stylesheet>". So it looks like the next-gen replacement 
of Gecko will end up supporting XUL/XBL after all. :-P Unclear is plans 
on how to deal with the XUL box model, XUL trees, or XUL lists, the 
latter two having some complex layout/content interactions.

> It sounds to me like Quantum, while being implemented incrementally, 
> is really ultimately deprecating Gecko itself, not just a couple of 
> components of it (XUL/XBL).

The key thing to recognize is that incremental changes require 
maintaining most of the existing interface. It's certainly possible, if 
not probable, that the exact API of, say, the HTML parser may change, 
breaking our libmime. But, for the most part, the queries we make (e.g., 
convert this DOM tree into an HTML string) aren't the kind of things 
that you're going to lose in the API, although we may lose the finesse 
of some of the knobs, breaking usually only rare, poorly-documented 
about:config options. As long as we're basically using the same surface 
that the Firefox frontend is, it's unlikely that any near-term, 
incremental change is going to break that surface. For that reason, I'm 
less concerned that we're using XUL <tree> than I am about, say, the 
fact that we're still using <RDF:datasource>.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist



More information about the tb-planning mailing list