<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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>
</p>
<p>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>
</p>
<p>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>
</p>
<p>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>
</p>
<ul>
<li>Lightning: to be integrated into the code base<br>
</li>
<li>Mozmill (used in our test infra): we're converting over to
using mochitests instead</li>
</ul>
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>
<p>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.</p>
<p>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, <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General">tell
us about it</a>. B) convert your add-on to a <a
moz-do-not-send="true"
href="https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html">Web
Extension Experiment</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>
</p>
<p> -Magnus<br>
</p>
</body>
</html>