<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Please see bug <span id="field-value-status_summary"><span
id="field-value-bug_id"><a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1571681">1571681</a>
tracking this conversion. </span> <span> <span
class="bug-time-label"></span></span></span> <br>
</p>
<p>In bug <span id="field-value-dependson"><a class="bz_bug_link
bz_status_ASSIGNED"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1585162"
title="ASSIGNED - Convert calendar Mozmill tests to Mochitest">1585162
</a><span class="bz_bug_link bz_status_ASSIGNED">there is
already a patch converting over all the calendar mozmill
tests, probably landing soon. You can see the approach from
there. <br>
</span></span></p>
<p>The timeline should within this 2019. <br>
<span id="field-value-dependson"><span class="bz_bug_link
bz_status_ASSIGNED"></span><a class="bz_bug_link
bz_status_ASSIGNED"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1585162"
title="ASSIGNED - Convert calendar Mozmill tests to Mochitest"></a></span></p>
<p> -Magnus<br>
</p>
<div class="moz-cite-prefix">On 02-10-2019 12:00, ISHIKAWA,chiaki
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:762f0345-d3c4-1e72-34be-fa4734387ea3@yk.rim.or.jp">I
have changed the subject line.
<br>
<br>
I am focusing on a side topic.
<br>
<br>
> Mozmill (used in our test infra): we're converting over to
using mochitests instead
<br>
<br>
So we are moving from mozmill to mochitests.
<br>
<br>
How is it planned?
<br>
<br>
I would like to see a smooth transition.
<br>
<br>
For example,
<br>
<br>
- rewriting test one by one from mozmill to mochitests and
<br>
create a duplicate set of existing tests (functional duplicates)
so that
<br>
equivalent of all the tests are available and have been
thoroughly tested
<br>
by the time we switch from mozmill to mochitests completely.
<br>
<br>
- Is there a document to describe how to rewrite mozmill tests to
mochitests to guide such conversion?
<br>
<br>
(- One thing I noticed is that there *ARE* xpcshell tests for TB,
but xpcshell test framework doesn't create
<br>
visible windows during tests and that cause some local hacks to
fail since
<br>
I could not produce visible error message to the user due to
lack of visible screen
<br>
when an serious I/O error occurs. I hope mochitests won't have
such strange restriction.
<br>
Oh well, since it checks the GUI operation as well, there WILL
be screens, I suppose.)
<br>
<br>
What is the planned timescale of the transition?
<br>
End of 2019 is unattainable.
<br>
Maybe the end of 2020?
<br>
<br>
TIA
<br>
<br>
Chiaki
<br>
<br>
<br>
<br>
On 2019/10/01 22:02, Magnus Melin wrote:
<br>
<blockquote type="cite">
<br>
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.
<br>
<br>
Since then, Thunderbird has been developing WebExtensions APIs
(aka MailExtensions), and the number of APIs available is
continuously growing:
<a class="moz-txt-link-freetext" href="https://thunderbird-webextensions.readthedocs.io/">https://thunderbird-webextensions.readthedocs.io/</a>
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
* Lightning: to be integrated into the code base
<br>
* Mozmill (used in our test infra): we're converting over to
using
<br>
mochitests instead
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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
<a class="moz-txt-link-rfc2396E" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General"><https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General></a>.
B) convert your add-on to a Web Extension Experiment
<a class="moz-txt-link-rfc2396E" href="https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html"><https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html></a>.
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.
<br>
<br>
-Magnus
<br>
<br>
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
</blockquote>
</body>
</html>