Intent to de-support: traditional add-ons

Magnus Melin mkmelin+mozilla at
Thu Oct 17 07:42:51 UTC 2019

I don't see how that would work... for that case it seems more 
reasonable to keep developing it as an add-on (experiment or not) and 
make sure the add-on users are paying or donating enough to the add-on 
to keep development of it sustainable.


On 16-10-2019 15:03, Axel Grude wrote:
> 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
> *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
> _______________________________________________
> 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