Resurrecting Embedded Gecko

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Thu Feb 4 21:33:34 UTC 2016


On 2/3/2016 1:55 AM, Jim Porter wrote:
> As many of you know, several years ago, Mozilla removed most of the
> support for embedding Gecko[1]. As the time, Benjamin Smedberg said that
> it might be worth revisiting embedding once we got multi-process
> rendering going. Since e10s is now a reality (in Aurora/Dev Edition) and
> the old-school XPCOM/XUL interfaces are on their way out, perhaps now is
> the time to revisit it.
>
> On the Connected Devices team (formerly Firefox OS), we're looking into
> embedded Gecko for prototyping and releasing various, well, connected
> devices. Thus, we're planning to propose resurrecting embedded Gecko as
> part of the Connected Devices initiative. Since there have been a lot of
> discussions about what to do with Thunderbird as XPCOM/XUL features go
> away, I wanted to see what all of you thought about this plan. Would
> this help provide Thunderbird with a stable future as a Gecko-based product?

I've said in the past that I thought it was a mistake for Mozilla to 
completely kill embedding. Unfortunately, at this point, Mozilla has 
also done a good job of burning bridges with respect to embedding. 
Having declared alternative embedding strategies only to retract them 
and close them a few years later on multiple occasions, it would be hard 
for any prospective embedding client to trust that Mozilla won't 
capriciously pull the plug on them with no alternative or warning.

What Thunderbird would need as a putative embedding client is probably 
the last thing Mozilla wants to commit to: stability, responsiveness to 
missing functionality, and, in general, a sense that Mozilla won't screw 
embedding over in a nothing-but-Firefox-matters fit. As Andrew says, 
without this kind of commitment, it's unlikely that embedding Gecko 
would be a satisfactory solution. On the other hand, I would opine that, 
given our resources and the complete lack-of-uniformity in various APIs, 
it's the one that we'd most likely end up with anyways.

> If there are any specific things you think Thunderbird would need, let
> me know and I'll try to incorporate that into our proposal.

Beyond the institutional support of Mozilla actually caring about 
embedding, and in a more narrow technical sense, the things that come 
most to mind are:
1. Custom URL protocol handlers (news:, imap:, mailbox:).
2. Exposure of platform APIs that are not exposed to the Web because 
they're "legacy," e.g., encoding to non-UTF-8, raw TCP socket support, 
"insecure" crypto protocols, etc.
3. nsIContentPolicy, and in general, fine-grained high-assurance 
sandboxing that lets us control anything that passes into or out of a 
sandbox.
4. The ability to expose native APIs to JS via a stable reflection 
mechanism.

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



More information about the tb-planning mailing list