Intent to de-support: traditional add-ons

Axel Grude axel.grude at
Wed Oct 16 12:03:09 UTC 2019

Dear Magnus,

> or add-on authors going forwards, there is of course also an option C (depending on 
> what the add-on does): work with us to integrate the functionality into core. 
I actually thought about this myself - if it means not losing the "privileged access" 
to the JavaScript / XPCOM layer it may mean a lot less work than constantly adapting 
an Add-on. There is only one problem - over the 10 years I am working4 on this project 
I have managed to turn it into a paid / self-employed thing, and with the amount of 
work ahead and to maintain the functionality, the only way to recoup would be to turn 
into a Thunderbird employee.

I am not sure if that's the correct way forward for me - would it possible to imagine 
a specialized / subcontractor position for an Add-ons developer so they can focus on 
just that specific work / functionality, rather than being deployed into stuff we may 
not be interested in?

The other argument against core is that only a small group of users may be interested 
in the functionality of these legacy extensions, and by rights /*they */should be the 
ones funding that. A "Thunderbird advanced" / freemium model might be a way out here. 
Just brain storming...


*Axel Grude <mailto:axel.grude at>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders 
quickFilters <>, 
QuickPasswords <>, Zombie Keys 
<>, SmartTemplate⁴ 
Visit my YouTube Channel <> for email 
productivity tips Get Thunderbird!
> *Subject:*Re: Intent to de-support: traditional add-ons
> *From:*Magnus Melin <mkmelin+mozilla at>
> *To:*<tb-planning at>
> *Sent: *Tuesday, 10/15/2019, 11:19 11:19 IST +0100 [Week 42]
> A few clarifications:
> The changes are for the general public only going to come into effect in the next 
> ESR release, Thunderbird 78 in mid 2020. For developers, in beta and nightly support 
> will start to disappear from core once we're ready do so, probably during 2019. Some 
> notable things that will be removed are the custom overlay loader (Overlays.jsm), 
> and support for add-ons requiring restart.
> For add-on authors going forwards, there is of course also an option C (depending on 
> what the add-on does): work with us to integrate the functionality into core. If the 
> add-on is under the bug-fix category this is certainly the way to go as no API for a 
> bug-fix would be in sight. In general we're happy to include functionality provided 
> it's of general usefulness.
> MailExtension Experiments is one way to go (and that's not deprecated), but should 
> not be seen as a long term solution. It may be a short term solution though. It 
> means you need to follow changes closely and things will often break. Sometimes in 
> ways that could be hard to solve. They simply need to be understood to be seen as 
> experiments, with no warranties.
>  -Magnus
> 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
> _______________________________________________
> tb-planning mailing list
> tb-planning at
-------------- 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