Intent to de-support: traditional add-ons

Magnus Melin mkmelin+mozilla at
Tue Oct 1 17:26:46 UTC 2019

Correct bugzilla link to file bugs about needed APIs is 


On 01-10-2019 16:02, Magnus Melin wrote:
> Since version 57, Firefox only supports add-ons through the 
> WebExtensions APIs. At the time, Thunderbird decided to continue 
> supporting traditional add-ons, since we hadn't yet been able to 
> develop replacing APIs for add-on developers to use.
> Since then, Thunderbird has been developing WebExtensions APIs (aka 
> MailExtensions), and the number of APIs available is continuously 
> growing:
> Because the toolkit support for traditional add-ons has been largely 
> removed, this has meant a lot of work for Thunderbird to keep things 
> going for add-ons. For the server side it has also meant a lot of 
> extra work ( is a fork of 
> Add-on developers haven't had an easy ride either: The number of 
> changes to make an add-on compatible has been significant.
> Going forwards we want to change this. Support for traditional add-ons 
> is going to be dropped as soon as we're ready to do so internally. 
> There are a few pieces of code that we need to convert over internally:
>   * Lightning: to be integrated into the code base
>   * Mozmill (used in our test infra): we're converting over to using
>     mochitests instead
> It's not yet clear exactly when we're ready to rip out the support for 
> traditional add-ons from the code base, but it should be whitin the 
> Thunderbird 72 time frame - so by end of 2019. The next major version 
> of Thunderbird, version 78, will be out around June 2020. Up until 
> then, code wise many things are going to change. For instance, what is 
> left of XUL will be gradually going away, and documents will shifted 
> to being XHTML with a less and less XUL flavor.
> Dropping support for non-MailExtension add-ons is also needed for 
> Supporting old-style add-ons would require a 
> significant investment in the back-end there, since the Django version 
> of the back-end would reach EOL and have to go through a painful and 
> expensive upgrade.
> As an author of a traditional add-on, what should you do? There are 
> two routes: A) convert your add-on to a MailExtension. If the API you 
> need doesn't exist yet, tell us about it 
> <>. 
> B) convert your add-on to a Web Extension Experiment 
> <>. 
> Most add-ons should be able to be converted to an experiment with a 
> reasonable effort. The recommended path is forward is to convert it to 
> an a MailExtension though. That will make sure the add-on works 
> without significant changes over many years. If you go with option B, 
> you'll have to maintain a lot of more code yourself and breakages can 
> and will be bad unless you keep up really close. MailExtension 
> Experiments should be seen as such, experiments with the goal of 
> getting the API they need into Thunderbird core. Please work with us 
> on getting the needed pieces in as a supported API. Initially we'll be 
> allowing experiments to be exposed to the general public, but over 
> time (years) Thunderbird will gravitate towards not having the 
> experiments available to the general public, the same way it works for 
> Firefox.
>  -Magnus
> _______________________________________________
> tb-planning mailing list
> tb-planning at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list