Caution about Thunderbird 52 and binary extensions

Axel Grude axel.grude at
Thu Nov 17 11:35:59 UTC 2016


Get Thunderbird!

> *Subject:*Re: Caution about Thunderbird 52 and binary extensions
> *From:*Chris <tb-planning at>
> *To:*Tb-planning
> *Sent: *Wednesday, 16/11/2016 21:47:16 21:47 GMT ST +0000 [Week 46]
> Hello,
> 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.
a lot of non-binary addons use (the scriptable parts of) XPCOM /directly /as well.
> 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.
this might be not practicable if Mozilla scraps this for the M-C codebase...
> 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.
Well changing in XPCOM interface can also lead to malfunctions in scripted Addons, a 
full crash of the host (Tb / SeaMonkey) would be a worst case scenario.
> 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)
XPCOM interfaces have always been changing, (albeit slowly) and we as Addon authors 
should keep an eye on them. The Addon validation process actually flags changed ones, 
but I am not sure whether it flags the complete list. A complete "interface history" 
tool that checks an Addon's code for recently changed XPCOM functions would be a big 
help here.
> 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?
As far as I know there is no immediate plan to scrap XPCOM support for Thunderbird. I 
am hoping that we can fork the code in order to avoid this as Thunderbird Addons are 
lot more "desktop-centric" than browser addons.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list