From mozmill to mochitests (Re: Intent to de-support: traditional add-ons)

Magnus Melin mkmelin+mozilla at
Wed Oct 2 09:06:54 UTC 2019

Please see bug 1571681 
<> tracking this 

In bug 1585162 
<>there is already a 
patch converting over all the calendar mozmill tests, probably landing 
soon. You can see the approach from there.

The timeline should within this 2019.


On 02-10-2019 12:00, ISHIKAWA,chiaki wrote:
> I have changed the subject line.
> I am focusing on a side topic.
> > Mozmill (used in our test infra): we're converting over to using 
> mochitests instead
> So we are moving from mozmill to mochitests.
> How is it planned?
> I would like to see a smooth transition.
> For example,
> - rewriting test one by one from mozmill to mochitests and
>   create a duplicate set of existing tests (functional duplicates) so 
> that
>   equivalent of all the tests are available and have been thoroughly 
> tested
>   by the time we switch from mozmill to mochitests completely.
> - Is there a document to describe how to rewrite mozmill tests to 
> mochitests to guide such conversion?
> (- One thing I noticed is that there *ARE* xpcshell tests for TB, but 
> xpcshell test framework doesn't create
>    visible windows during tests and that cause some local hacks to 
> fail since
>    I could not produce visible error message to the user due to lack 
> of visible screen
>    when an serious I/O error occurs. I hope mochitests won't have such 
> strange restriction.
>    Oh well, since it checks the GUI operation as well, there WILL be 
> screens, I suppose.)
> What is the planned timescale of the transition?
> End of 2019 is unattainable.
> Maybe the end of 2020?
> Chiaki
> On 2019/10/01 22: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: <>

More information about the tb-planning mailing list