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. 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
4. The ability to expose native APIs to JS via a stable reflection
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning