Thunderbird and Addons

Joshua Cranmer pidgeot18 at
Wed Aug 26 20:14:41 UTC 2015

On 08/26/2015 02:44 PM, R Kent James wrote:
> It would be good to inform us of any binary extensions that are out 
> there and your needs.

This is extremely crucial advice to add-on developers. Anything that 
cannot be satisfied with js-ctypes we should be well-informed of, 
because we're unlikely to be able to maintain this.
> We have no current plan for dealing with the XUL deprecation issue. We 
> don't get invited to sit at the cool kids table anymore, so this is 
> hitting us about the same time it is hitting you (though I suspect the 
> discussion was public if we had looked hard enough).

In a recent message, I've referred to the XUL/XPCOM issue as a "looming 
disaster" (to steal the term from a video game). XUL we're going to have 
to move away from, for sure. I do suspect, however, that there will 
remain a chrome/content divergence in the layout engine without HTML, 
and if that is the case, we should be able to use WebIDL to bridge JS 
and C++ in a post-XPCOM world (I already know at a high-level what needs 
to be done, and I've had support from bz about our use cases here in the 
past). I do have ideas on how to do that. It's very unclear to me how 
WebExtensions would handle custom WebIDL APIs, but if that is possible, 
we could use it.

The bigger problem with the deletion of XUL is that XUL has some 
high-quality widgets that are very difficult to code in pure 
HTML--namely, I'm referring to the <tree> widget. Honestly, this is 
something that I feel Mozilla should be providing if they move away from 
XUL, but I doubt they will (judging from the response to the last XUL 
tree question on m.d.platform).

> At least for Thunderbird, we have no current intention of either 
> trying to reduce the power of addons, nor trying to be compatible with 
> some industry-wide standard for addons (since there is no equivalent 
> to "Web Extensions" for email clients). We're a different product than 
> Firefox with different needs. But the prospect of trying to do our own 
> thing here independent of Firefox would be enormously challenging.

There are some extensions for FF that do things like add new protocol 
handlers whose support would require some sort of hooks that we could 
likely abuse/twist for our ends. Some of the documentation makes it 
clear that the add-ons team has no answers for these questions (nor even 
really considered them too hard). This makes proactive damage control 
extremely difficult on our end (or even for many/most add-on authors).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list