Caution about Thunderbird 52 and binary extensions

Chris tb-planning at
Wed Nov 16 21:47:16 UTC 2016


BirdieSync software has a third-party add-on in Thunderbird which relies 
on XPCOM and XUL through binary components, and uses the needed XPCOM 
interfaces to access to contacts, calendars and mails to provide 
synchronization with mobile devices.

The future disappearance of support of binary add-ons hugely impacts 
BirdieSync since it requires a full rewriting of Thunderbird add-on. 
Such a rewriting takes a lot of time, introduces risk in term of 
regressions and takes time to deeply test it.

Being able to still rely on binary add-ons in Thunderbird version 52 
would leave more time to smoothly manage the transition.

Now the question is to know what the impacts would be of such a support. 
You mentioned that a problem could be the "stability of interfaces and 
exported symbols over the lifetime of the product in security updates". 
So I guess that if one XPCOM interface is modified during a security 
update, it means that a binary add-on relying on this interface could 
crash. The solution in this case, could be to publish a new version of 
the add-on to adapt to the binary changes (as it was done for all major 
versions of Thunderbird). I also assume that the change of interface 
would also impact Javascript add-ons, but with no risk of crash though. 
But I only see that from an add-on point of view. Maybe there are more 
important impacts in Thunderbird I'm not aware of and you could clarify 
this point for me.

Also can you confirm that in Thunderbird 52, all XPCOM interfaces that 
were accessible through binary components will still be accessible 
through JavaScript components ? (so not with a complete change of 
interface like WebExtensions)
What are the forecasted availability of all XPCOM interfaces in future 
releases of Thunderbird, even in Javascript, since it seems that Firefox 
wants to restrict its available interface to add-on developers to 
WebExtensions  ?
Do you have a rough idea about when Thunderbird 52 would be released ?



Le 11/16/2016 à 7:06 PM, R Kent James a écrit :
> For a long time now, we have planned to stop supporting binary
> extensions in Thunderbird 52. Binary extensions have been disabled in
> Firefox for awhile now, and it has become increasingly untenable to
> maintain that capability in Thunderbird.
> Currently, the only known active users of binary extensions have all
> been with extensions close to the core project: Lightning, ExQuilla, and
> some Chat extensions. All of these groups gave been pursuing other
> options, though it is not clear if the options are entirely problem free.
> In mozilla core, bug 1314955 exists which intends to completely remove
> the capability for binary extensions from the core code. That bug was
> originally planned to land in gecko 52, but it missed the deadline and
> landed instead in gecko 53 (but was backed out, presumably temporarily,
> due to testing regressions). Even if it lands in mozilla-esr52, we would
> still presumably have the option of backing it out in the branch of
> m-esr52 that we will use to build TB 52.
> Some may have the hope that we could continue to support binary
> extensions in TB 52 if bug 1314955 does not land in mozilla-esr52. I
> just want to point out that it is more complicated than just that bug.
> In additional to maintaining the capability, binary compatibility also
> relies on a commitment to maintain stability of interfaces and exported
> symbols over the lifetime of the product in security updates. There was
> a weak commitment to this from the Firefox maintainers in mozilla-esr45,
> but there will be zero commitment to this in mozilla-esr52.
> Maintaining binary compatibility in Thunderbird 52 would require a
> commitment from the comm-esr52 manager (presumably to be Jörg) that we
> will watch for interface and export changes in mozilla-esr52, and
> prepare corrected versions of those bugs for our version branch of
> mozilla-esr52 that would be safe for binary compatibility. This would
> not be a trivial commitment, and I would recommend against that.
> We have not yet landed any changes to comm-central that specifically
> disable binary extensions. I think though that we should do that, and
> land in the comm train that leads to TB 52, so that we are forced to
> face reality.
> Or is someone prepared to argue that we should attempt to maintain
> binary extension compatibility in Thunderbird 52?
> :rkent
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list