From mozmill to mochitests (Re: Intent to de-support: traditional add-ons)
mkmelin+mozilla at iki.fi
Wed Oct 2 09:06:54 UTC 2019
Please see bug 1571681
<https://bugzilla.mozilla.org/show_bug.cgi?id=1571681> tracking this
In bug 1585162
<https://bugzilla.mozilla.org/show_bug.cgi?id=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
> equivalent of all the tests are available and have been thoroughly
> 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?
> 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: https://thunderbird-webextensions.readthedocs.io/
>> 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 (addons.thunderbird.net is a fork of addons.mozilla.org).
>> 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
>> addons.thunderbird.net. 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.
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning