Caution about Thunderbird 52 and binary extensions
tb-planning at birdiesync.com
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
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
interface like WebExtensions)
What are the forecasted availability of all XPCOM interfaces in future
wants to restrict its available interface to add-on developers to
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?
> tb-planning mailing list
> tb-planning at mozilla.org
More information about the tb-planning