Intent to de-support: traditional add-ons

944 views
Skip to first unread message

Magnus Melin

unread,
Oct 1, 2019, 9:02:49 AM10/1/19
to Thunderbird planning (moderated)

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.

 -Magnus

Eyal Rozenberg

unread,
Oct 1, 2019, 10:38:02 AM10/1/19
to Thunderbird planning (moderated), Magnus Melin
I don't understand what it is you're telling us. Starting with
Thunderbird 68, traditional add-ons aren't supported. Support has
already been dropped. So what exactly will be dropped in TB 72 that
hasn't been already?

As for ATN, remember that TB 60 and earlier versions will still be
running for quite a long time. It would be unfortunate if those would
lose accesss to an extensions website.

Eyal


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: 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

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fenter_bug.cgi%3Fproduct%3DThunderbird%26component%3DGeneral&data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C0143db32c0774fe0fad308d7466faa18%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055318541329953&sdata=rvgEOyYjBzYH1NFe7UkwPQtBTWcPO2feqUJAi%2BYBJK0%3D&reserved=0>.


> B) convert your add-on to a Web Extension Experiment

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthunderbird-webextensions.readthedocs.io%2Fen%2F68%2Fhow-to%2Fexperiments.html&data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C0143db32c0774fe0fad308d7466faa18%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055318541339950&sdata=ET8%2F3esss%2FbqEyWi99wLdyID2jHJ1bmRtSNLr%2BLaYOo%3D&reserved=0>.


> 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-pl...@mozilla.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Ftb-planning&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C0143db32c0774fe0fad308d7466faa18%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055318541359930&amp;sdata=u0yzGYuTouWKgMHvMrUGUQlsP6QDjIQG%2FiwZu1tPFhM%3D&amp;reserved=0
>
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

John Bieling

unread,
Oct 1, 2019, 11:21:48 AM10/1/19
to tb-pl...@mozilla.org
He is talking about dropping support for the "legacy" key in your
manifest.json. Which means only true WebExtensions will be supported.

From Thunderbirds point of view, TB60 will reach EOL soon. Anything
older is already EOL. And usually they do not keep code, that is only
needed for EOL products ...

John

Eyal Rozenberg

unread,
Oct 1, 2019, 12:01:09 PM10/1/19
to Thunderbird planning (moderated), John Bieling
Ah, in that case I'm vehemently opposed to Magnus' suggestion.

Me (and others) have put our own share of work to adapt our extensions,
and we should not have the rug pulled from under us just when we've
gotten ourselves on some half-stable footing.

Magnus Melin wrote:
> Going forwards we want to change this.

Please don't.

What is the point of everybody's hard work if it's just being thrown away?


John Bieling wrote:
> From Thunderbirds point of view, TB60 will reach EOL soon.

In what way? Hunderds of thousands (if not millions) of users will
continue using v60 and versions well before 60 for a few years going
forward. Not to mention the fact that TB 52 with lots of extensions
beats TB 68 or later with a lot less extensions, for many people.

Eyal

On 01/10/2019 18:11, John Bieling wrote:
> He is talking about dropping support for the "legacy" key in your
> manifest.json. Which means only true WebExtensions will be supported.
>
> From Thunderbirds point of view, TB60 will reach EOL soon. Anything
> older is already EOL. And usually they do not keep code, that is only
> needed for EOL products ...
>
> John
>
>
> Am 01.10.2019 um 15:45 schrieb Eyal Rozenberg:
>> I don't understand what it is you're telling us. Starting with
>> Thunderbird 68, traditional add-ons aren't supported. Support has
>> already been dropped. So what exactly will be dropped in TB 72 that
>> hasn't been already?
>>
>> As for ATN, remember that TB 60 and earlier versions will still be
>> running for quite a long time. It would be unfortunate if those would
>> lose accesss to an extensions website.
>>
>> Eyal
>>
>>
>> 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:

>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthunderbird-webextensions.readthedocs.io%2F&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128419768&amp;sdata=DtA6WMLScsSU2utHOmesUVap4UYBfAnbm7OJQABnVhY%3D&amp;reserved=0

>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fenter_bug.cgi%3Fproduct%3DThunderbird%26component%3DGeneral&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128419768&amp;sdata=mXbAhT07zFlk5IEQeAEH7rILNN3YAYUTbGVLENeBlq4%3D&amp;reserved=0>.


>>>
>>> B) convert your add-on to a Web Extension Experiment

>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthunderbird-webextensions.readthedocs.io%2Fen%2F68%2Fhow-to%2Fexperiments.html&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128419768&amp;sdata=YHyDPp0Id0xBY9qHXBsf2iEVFHeIXmMiOo2pKjlS%2BC0%3D&amp;reserved=0>.


>>>
>>> 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-pl...@mozilla.org

>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Ftb-planning&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128419768&amp;sdata=PB%2FojXXYXVexBs59S7SNIBQqloDTV3rnRwQTo9HHcuY%3D&amp;reserved=0


>>>
>>>
>> _______________________________________________
>> tb-planning mailing list
>> tb-pl...@mozilla.org

>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Ftb-planning&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128429759&amp;sdata=nI6tAXMxycjlTwDLDewE4HuMVq2jaZ8B1ADDkPck6ig%3D&amp;reserved=0


>>
> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org

> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Ftb-planning&amp;data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C14fa1a336aba43dce7ab08d74683157d%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055401128429759&amp;sdata=nI6tAXMxycjlTwDLDewE4HuMVq2jaZ8B1ADDkPck6ig%3D&amp;reserved=0

Emmanuel SELLIER

unread,
Oct 1, 2019, 12:37:28 PM10/1/19
to Thunderbird planning (moderated)
Hello,

Could you explain what you mean in :
TB72 would be publicly released before end of 2019?
Or the deadline (for the public) is TB78?

The remaining time is quite short;
We haven't moved to MailExtension since the API did not meet (yet) all of our needs.

Regards,
Emmanuel

>>> On 01/10/2019 16:02, Magnus Melin wrote:
>>>>
>>>>
>>>> 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.

Magnus Melin

unread,
Oct 1, 2019, 1:26:56 PM10/1/19
to tb-pl...@mozilla.org

Correct bugzilla link to file bugs about needed APIs is <https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=Add-ons:%20Extensions%20API>

 -Magnus

Walter L Schwartz

unread,
Oct 1, 2019, 1:42:13 PM10/1/19
to tb-pl...@mozilla.org

Magnus Melin

unread,
Oct 1, 2019, 2:28:08 PM10/1/19
to tb-pl...@mozilla.org
On 01-10-2019 18:39, Eyal Rozenberg wrote:
> Ah, in that case I'm vehemently opposed to Magnus' suggestion.
>
> Me (and others) have put our own share of work to adapt our extensions,
> and we should not have the rug pulled from under us just when we've
> gotten ourselves on some half-stable footing.

This is not pulling the rug, it's just about removing support for
dead-end technologies and pointing people to a better and all-in-all
easier way of achieving the goals. Of course it requires some work, but
longer term less so.

>
> Magnus Melin wrote:
>> Going forwards we want to change this.
> Please don't.
>
> What is the point of everybody's hard work if it's just being thrown away?
>
>
> John Bieling wrote:
>> From Thunderbirds point of view, TB60 will reach EOL soon.
> In what way?

As usual, the 60 ESR cycle is coming to an end. There are not going to
be any further (even) security fixes for the 60 series. The next upgrade
step is to Thunderbird 68. With the 68.2 release, the 60.x series is EOL.

> Hunderds of thousands (if not millions) of users will
> continue using v60 and versions well before 60 for a few years going
> forward. Not to mention the fact that TB 52 with lots of extensions
> beats TB 68 or later with a lot less extensions, for many people.

The numbers are small: Thunderbird 52 now has under 2.5% of users. But I
don't think older versions is relevant to this discussion.

 -Magnus


_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org

https://mail.mozilla.org/listinfo/tb-planning

Magnus Melin

unread,
Oct 1, 2019, 2:32:08 PM10/1/19
to tb-pl...@mozilla.org
To clarify, Thunderbird 72 is only a beta. We only release final
versions on the ESR cycle, so for end users next versions after
Thunderbird 68 will be (likely) Thunderbird 78.

So add-on authors have time to adapt until next summer, but always best
to start early.

 -Magnus

ISHIKAWA,chiaki

unread,
Oct 2, 2019, 5:00:57 AM10/2/19
to tb-pl...@mozilla.org
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?

TIA

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: 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

> <https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General>.

> B) convert your add-on to a Web Extension Experiment

> <https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html>.

> 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
>
>

Magnus Melin

unread,
Oct 2, 2019, 5:07:05 AM10/2/19
to tb-pl...@mozilla.org

Please see bug 1571681 tracking this conversion.

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.

 -Magnus

Patrick Brunschwig

unread,
Oct 2, 2019, 5:44:49 AM10/2/19
to Thunderbird planning (moderated)
Eyal Rozenberg wrote on 01.10.2019 17:39:
> Ah, in that case I'm vehemently opposed to Magnus' suggestion.
>
> Me (and others) have put our own share of work to adapt our extensions,
> and we should not have the rug pulled from under us just when we've
> gotten ourselves on some half-stable footing.

This is not a surprising step -- or at least not for me. Given how
aggressively old code is being removed from Firefox, and thus from
Thunderbird, this moment had to come one day or another. It has been
clear for several years that Thunderbird will not be able to continue to
support classical ("legacy") add-ons forever.

The Thunderbird developers already had to invest quite some substantial
effort in making legacy add-ons work until now. But as the pain grows,
it's time to cut that dead end and work on something much more future-proof.

-Patrick

ISHIKAWA,chiaki

unread,
Oct 2, 2019, 5:52:41 AM10/2/19
to tb-pl...@mozilla.org
I think somebody ought to raise a red flag here.

At last count, there were 32 test subdirectories and the total tests
were somewhere in 1100-1200 range.
(A single file can contain multiple tests.)

I wonder who are working on the conversion aside from Geoff.

I didn't realize this 2019 timeline, BTW.
Schedule-wise, three months remain meaning more than 10 tests (in a few
files) need to be converted daily.

I, for one, have looked at some tests before in order to understand why
some tests fail due to my CPP file changes, but could not make head or
tail of them at all, honestly speaking.
For example, I am trying to figure out why my local patches fail the
following test, but
I could not fathom exactly what it is trying to do. Too sparse
documentation of mozmill, I am afraid.

comm/mailnews/base/test/unit/test_quarantineFilterMove.js


I wonder if there are enough man-power for the conversion in time.
I am happy to be corrected if I am wrong.

If mochitests is easier to understand than mozmill, that would be super
in the end for extending tests in general and adding new tests: there
are many things that don't get checked properly  in current mozmill
test. For example, I notice that some tests are not handling error
dialog correctly at all. They either look at incorrect dialog and
decided that the error is handled or never expected to encounter extra
error dialogs at all.
In fact, there are cases where incorrect error dialog seems to be
processed as the expected one  and the other
error dialog is simply ignored and timed out if I am not mistaken. You
can look at the mozmill test screen and see such strange error dialog
shown on the screen for timeout period and the test basically pauses
until timeout kicks in and only then whlole test proceeds again.
The whole mozmill test takes less than two hours now on my Ryzen 1700
CPU and so
you can simply run the test in the background and make the screen
visible, and then do some other work on PC.
You will eventually notice that there are moments of frozen screen with
error dialog being shown and nothing happens. It is hard to miss.

TIA

Chiaki


On 2019/10/02 18:06, Magnus Melin wrote:
>
> Please see bug 1571681
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1571681> tracking this
> conversion.
>
> In bug 1585162
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1585162>there is already

Will

unread,
Oct 2, 2019, 2:16:30 PM10/2/19
to tb-pl...@mozilla.org
On 01/10/19 20:27, Magnus Melin wrote:
>
> The numbers are small: Thunderbird 52 now has under 2.5% of users. But
> I don't think older versions is relevant to this discussion.
>

Yup - unfortunately we are part of that 2.5% and older versions ARE
relevant to this discussion (I wonder how many were force upgraded to
60+ and wanted to go back but didn't know how, and how many were so
angry they just dumped TB altogether?)

And the reason is that we can't get updated extensions from the
developers, nor find anyone willing to update them, even for $$$$$

They are not even that complicated, but..... I just can't find anyone,
but then I guess that is a direct response to the waning TB user base.
Less users, less developers.

So we are stuck in a hole and abandoned by TB, despite our best efforts.

It really isn't nice being told we are wrong and out of touch and
irrelevant and that paradise lives over the next rainbow.

In fact it is intensely annoying.

So for us, 52.x with a couple of extensions does exactly what we want,
which is more than can be said for your shiny new things.

"All that glisters is not gold"

And it will stay that way until we get something fixed or move to an
alternative solution.

I agree with the comments from Eyal who hits the nail pretty squarely on
the head.

Jörg Knobloch

unread,
Oct 2, 2019, 4:27:36 PM10/2/19
to tb-pl...@mozilla.org
On 02 Oct 2019 17:49, Will wrote:
> And the reason is that we can't get updated extensions from the
> developers, nor find anyone willing to update them, even for $$$$$
>
> They are not even that complicated, but..... I just can't find anyone,
> but then I guess that is a direct response to the waning TB user base.
> Less users, less developers.
>
> [snip
>
> So for us, 52.x with a couple of extensions does exactly what we want,
> which is more than can be said for your shiny new things.

Just as a matter of interest: Which ones are so important and not
updated since TB 52?

Jörg.

Geoff Lankow

unread,
Oct 2, 2019, 5:04:44 PM10/2/19
to tb-pl...@mozilla.org
Three months is plenty of time to convert the remaining tests. I think
you over-estimate how little actually needs to be done to most tests for
them to work in Mochitest.

In most cases it involves (1) making sure the test can import the
supporting files it needs, (2) renaming the test files to match the
Mochitest convention and adding a manifest to each directory, and (3)
making some small changes to the file itself. I've already done part 1
for all the files.

GL

Andrei Hajdukewycz

unread,
Oct 2, 2019, 7:18:58 PM10/2/19
to Thunderbird planning (moderated), Will
On 10/2/2019 8:49 AM, Will wrote:
> Yup - unfortunately we are part of that 2.5% and older versions ARE
> relevant to this discussion (I wonder how many were force upgraded to
> 60+ and wanted to go back but didn't know how, and how many were so
> angry they just dumped TB altogether?)
>
> And the reason is that we can't get updated extensions from the
> developers, nor find anyone willing to update them, even for $$$$$
>
> They are not even that complicated, but..... I just can't find anyone,
> but then I guess that is a direct response to the waning TB user base.
> Less users, less developers.
Just for reference: Starkly unlike Firefox the TB user base is NOT
waning. In fact, it is steadily growing. Very slowly - on the order of
1-2% per year - but definitely growing. The popular conception that
Thunderbird is dying or that add-on related decisions have a significant
affect on the user base are incorrect. In fact, Thunderbird's long term
growth rates are healthier than Firefox's even though our total number
of users is only about 12% of theirs depending on how you do the math.

I completely understand that it's annoying to be told that old versions
are not relevant, but this is not done because we're trying to be mean
or because we don't care. It's just that there is a stark reality --
when infrastructure is discontinued and versions reach a certain age, we
completely lose the ability to do builds. And we can't just "spend the
time to do 52 builds again", because that would have a devastating cost
on development for the majority of users, which has to take priority if
Thunderbird is expected to survive.

There is a common attitude among add-on users and users of old versions
that they are representative of the users of Thunderbird, when it's
actually the opposite. They are, in fact, edge cases which tend to
consume a lot of time per user from developers. And the business case
for spending 1 hour of developer time on 2% of users compared to
spending that same amount of time to benefit 98% of users should be clear.

Of course we don't make decisions like this all the time. We care about
the community. The fact that legacy add-ons were even preserved at all
in 68 in any form is a testament to how much we care about all of our
users. Huge amounts of developer time were spent to make this happen,
and that only benefits the 5-10% of users who even install and use
add-ons that aren't Lightning.

I am sorry that you're stuck on old versions due to add-ons that you
can't easily update, but as much as I do personally care about users, at
a certain point if software isn't doing what you need it to do, it only
makes sense to just go find new software that will do what you need. And
if that's not Thunderbird, that's OK. We can't spend a herculean effort
to keep every single user. If we tried to, it wouldn't even be
successful in the end, because misusing our time that heavily would be
the actual thing that would kill the project dead.

Andrei
Thunderbird Infrastructure Engineer

Eric Moore

unread,
Oct 2, 2019, 9:27:13 PM10/2/19
to tb-planning
I understand the motivation for wanting to drop all support for legacy
add-ons in future releases but

(1) I don't understand why its so terrible to continue to store (and
distribute) legacy add-ons on Thunderbird.net for one more year while
waiting for a fleshed out/more usable MailExtensions API to be
available, and more legacy add-ons to be rewritten as MailExtensions.
Please elaborate on the reasoning why dropping legacy add-ons support in
future versions and whats available in thunderbird.net need to be so
tightly coupled.

(2) Why can't the legacy add-ons on Thunderbird.net be made available
somewhere else? Perhaps add a "legacy add-ons" entry to the add-ons list
box at Thunderbird.net that displays a single web page with download
links for all of the legacy extensions and complete themes that support
at least version 52. Users wouldn't be able to fetch them from within
Thunderbird, its not as convenient as if each had their own add-on page,
and some useful information is lost but at least all of the legacy
add-ons wouldn't just disappear.

(3) What is the target date for when the MailExtensions API (not the
Experiments API) is expected to have the API most legacy add-ons authors
need, if things go well?

From: Magnus Melin <mkmelin...@iki.fi>
> To: "Thunderbird planning (moderated)" <tb-pl...@mozilla.org>
> Subject: Intent to de-support: traditional add-ons
>
> 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.
>

Óvári

unread,
Oct 2, 2019, 9:27:14 PM10/2/19
to Jörg Knobloch, Ryan Sipes, Thunderbird planning (moderated), Will, Eyal Rozenberg

Hi Jörg,

Is "DL FileLink Provider for Thunderbird" one add-on that is so important and not updated since TB 52?

DL FileLink Provider for Thunderbird
https://addons.thunderbird.net/addon/dl-for-thunderbird/
https://www.thregr.org/~wavexx/software/dl/thunderbird.html

This add-on is required for Thunderbird users who are in the EU due to the General Data Protection Regulation (GDPR).
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
https://gdpr-info.eu/

It is understood that third-party FileLink add-on providers like Box, Dropbox can not be used without breaking the GDPR.

https://github.com/DownloadTicketService/dl/issues/74

https://github.com/DownloadTicketService/dl/issues/74#issuecomment-505949140

http://forums.mozillazine.org/viewtopic.php?f=19&t=3051338

What is the way forward to enable the "DL FileLink Provider for Thunderbird" add-on be updated for Thunderbird 68?

Thank you

Óvári

P.S. Should other add-ons to be highlighted?

Magnus Melin

unread,
Oct 3, 2019, 4:05:29 AM10/3/19
to tb-pl...@mozilla.org
On 03-10-2019 02:06, Eric Moore wrote:
> I understand the motivation for wanting to drop all support for legacy
> add-ons in future releases but
>
> (1) I don't understand why its so terrible to continue to store (and
> distribute) legacy add-ons on Thunderbird.net for one more year while
> waiting for a fleshed out/more usable MailExtensions API to be
> available, and more legacy add-ons to be rewritten as MailExtensions.
> Please elaborate on the reasoning why dropping legacy add-ons support
> in future versions and whats available in thunderbird.net need to be
> so tightly coupled.

Anyone is of course (like now) free to host an add-ons collection on
their site.

For Thunderbird's side officially, it makes no sense for us to host
add-ons that the application would not support. Maybe to clarify,
addons.thunderbird.net will still host the traditional add-ons until
Thunderbird 68 is EOL, so until sometime late 2020.

>
> (2) Why can't the legacy add-ons on Thunderbird.net be made available
> somewhere else? Perhaps add a "legacy add-ons" entry to the add-ons
> list box at Thunderbird.net that displays a single web page with
> download links for all of the legacy extensions and complete themes
> that support at least version 52. Users wouldn't be able to fetch them
> from within Thunderbird, its not as convenient as if each had their
> own add-on page, and some useful information is lost but at least all
> of the legacy add-ons wouldn't just disappear.

Well they can, it's just not Thunderbird's job to cater for that.

Other than that, we don't want to encourage anyone to stay on an old
version. You do realize there are *many* security fixes going into
releases every few weeks? Just look at
https://www.mozilla.org/en-US/security/advisories/

>
> (3) What is the target date for when the MailExtensions API (not the
> Experiments API) is expected to have the API most legacy add-ons
> authors need, if things go well?

I don't think that can be answered. Developers always "need" more than
they have. Expect additions to what we currently have, but full parity
is not achievable through APIs. Old style add-ons could virtually do
almost anything, and you can't provide an API to do anything.

 -Magnus

Emmanuel Sellier

unread,
Oct 3, 2019, 4:31:57 AM10/3/19
to Thunderbird planning (moderated)
I fully understand, and agree, that it is necessary for TB to continue to evolve as closely as possible to Firefox's evolutions (for security reasons, in particular).
However, I am somewhat concerned about the sequence of these developments. What will happen if Mozilla decides to fully adopt Google's Manifest V3 for Firefox extensions? Will it then be necessary to redevelop everything again?
https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/


Translated with www.DeepL.com/Translator

Magnus Melin

unread,
Oct 3, 2019, 4:54:37 AM10/3/19
to tb-pl...@mozilla.org

If and when Manifest v3 is adapted by Mozilla, Thunderbird would also adapt. But this is hardly about redeveloping everything once again. It's a non backwards-compatible change, but AIUI, changes would generally not be significant (YMMV).

 -Magnus

Jacques Angevelle

unread,
Oct 3, 2019, 7:07:22 AM10/3/19
to tb-pl...@mozilla.org
Hello,

To be short I am sorry that, for examples, SlideShow, NotTo  and
ExpiryTimeStamp are not updated. I don't remove them from TB hoping they
will be revived as they help daily use of TB.

Jacques

Mark Banner

unread,
Oct 3, 2019, 7:33:43 AM10/3/19
to tb-pl...@mozilla.org
On 03/10/2019 10:28, Jacques Angevelle wrote:
To be short I am sorry that, for examples, SlideShow, NotTo  and
ExpiryTimeStamp are not updated. I don't remove them from TB hoping they
will be revived as they help daily use of TB.

It might not be quite what you want, but Thunderbird Conversations has a gallery view for image attachments as well as many other things.

There may be others around (disclaimer: I help keep Conversations going).

Mark.

Patrick Cloke

unread,
Oct 3, 2019, 7:58:26 AM10/3/19
to tb-pl...@mozilla.org
I think it is important to note here that if there are APIs missing,
please let people know. What APIs get added is somewhat up to feedback
received from add-on authors. The development team doesn't know every
use-case of every add-on!

--Patrick

Will

unread,
Oct 3, 2019, 7:00:16 PM10/3/19
to Thunderbird planning (moderated)
On 03/10/19 01:36, Óvári wrote:

Hi Jörg,

Is "DL FileLink Provider for Thunderbird" one add-on that is so important and not updated since TB 52?

DL FileLink Provider for Thunderbird
https://addons.thunderbird.net/addon/dl-for-thunderbird/
https://www.thregr.org/~wavexx/software/dl/thunderbird.html


That's the killer one for us. Wrong ends of slow ADSL, places that can't accept some attachments, don't want to entrust stuff to certain cloud providers, overkill to try and setup something like nextcloud just for this.

I also have a plugin that lets us attach emails to Contacts in our CRM (vtiger/Corebos) which we use a lot (the webmail in the CRM is horrendous)

I *may* be able to get someone to work on the CRM plugin but haven't bothered looking until we get DL fixed as we can't upgrade without that.

I also note also that the G Calendar plugin (which I personally hate but was adopted long before me) is likely to be converted to CalDav which will have an effect as well, but I haven't even got that far yet.

I am not against progress. But I don't think that such a huge change was managed that well, especially when there were things still not fixed on the release of 60 which made it hard or impossible for some add on devs to update. It's the plugins that make TB what it is.

We were railroaded into 60, and the speed at which the old packages were removed made it extremely difficult to downgrade. I was lucky I found a set which I have preserved if anyone wants them.

So yes there was rapid take up, but hardly surprising. It was a fait accompli with most having zero choice and no idea what was going to break.

Anyways, that's us. Stuck until either something magical pops up or we go elsewhere.

Jörg Knobloch

unread,
Oct 3, 2019, 7:00:24 PM10/3/19
to tb-pl...@mozilla.org
On 01 Oct 2019 15:02, Magnus Melin wrote:
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.

I think this is not the right way to go about it.

What we should do is look at selected set of add-ons and see what they do. This is not hard, since developers are also add-on authors and many add-on authors are also volunteers.

Take some examples:

Quick Folder Move written by Philipp: Changes a context menu, the one for "Move To", takes a search string in popup that pops up from the context menu, searches for folders matching the string, presents a menu with the result, lets the user pick one, moves the messages. Doable with today's set of APIs? If not, there's something missing.

Shrunked image resizer written by Geoff: Observes the message body and attachment bucked of the compose window for images being added, offers to resize those images in a notification in the status bar, resizes them and changes the item in the message body or attachment bucket. IOW, it messes with the message body. Doable with today's set of APIs?

ThunderHTMLedit written by me: Adds a tab to the compose windows' body, lets switch to the tab to display the HTML of the message. It doesn't need to be a tab, it could be another toggle. Lets user edit the HTML in a 3rd party HTML editor, and when the user switches back to the message body, replaces the body with the HTML. Doable with today's set of APIs?

Various add-ons add a custom column to the thread pane/message list. Doable with today's set of APIs?

If I spent 10 more minutes on this, I could come up with another set of "common" scenarios. I'm sure, Axel could provide a list of what his complex add-ons do. I don't know much about them, but they do some stuff already mentioned above. I think messing with the message being composed is very common to many add-ons, like the ones mentioned or QuickText or SmartTemplate.

In summary: It's not efficient to let add-on authors discover that is needed, it's more efficient to go through some common functionality and check whether it is covered by APIs or not.

Jörg.

Mihovil Stanić

unread,
Oct 3, 2019, 7:00:25 PM10/3/19
to Thunderbird planning
SlideShow is great and useful  addon. Something similar should be considered implementing as Thunderbird feature (preview if all images inside email).

It's only addon that's keeping me on 60.x (60 isn't officially supported but you can hack it to work).


-------- Izvorna poruka --------
Šalje: Mark Banner <mba...@mozilla.com>
Datum: 03. 10. 2019. 13:33 (GMT+01:00)
Predmet: Re: Intent to de-support: traditional add-ons

Eyal Rozenberg

unread,
Oct 3, 2019, 7:00:30 PM10/3/19
to Thunderbird planning (moderated), Andrei Hajdukewycz, Will
Andrei, with due respect, I'd like to partially disagree with what you
wrote, particularly (but not only) regarding statistics.

Before doing so, however, I want to ask the list of some clarification
regarding the methodology with which we gather usage statistics: Under
what circumstances; which users have stats collected; what happens to
people whose older versions don't know about ATN; etc. If someone could
write a few paragraphs about this (or send a link) I'd be grateful.

More to the point, though:

1. Quoting an annual 1-2% userbase growth rate does not say much about
what happened over the past few months, when a lot of extension support
was lost. Do you have stats for that?

2. About being "non-representative" - that can be a sort of a false
truth. Example: If you write email using a right-to-left language like
Farsi, Arabic or Hebrew, your experience with TB is a constant
annoyance; it's quite uncomfortable to use before of mis-direction. So,
the BiDi Mail UI extension is essentially a must. However - there are
currently only < 2.5K users of this extension, according to
Christopher's statistics. This is not because users don't need/want it -
it's because the large number of potential users who might have used TB
had they known about it / seen TB with it - are simply unaware of it. If
there had been awareness, the extension user-base would have been
massively larger - since with the extension, the convenience balance
slants in favor of TB over other mail clients and some/most webmail apps
w.r.t. RTL text display.

What that means is that treating relatively-low-usage extensions as
non-representative is myopic; and not significantly catering to
extensibility blocks most of the potential of user base increase.

3. 1-2% annual user base growth is more of a stagnation than growth a
slight waning of the user base; the population in countries in which TB
is popular is growing at a higher rate than that, I would guess. I'm not
saying that's a bad thing considering the objective circumstances,

4. There is a huge difference between the part of the user base who use
Thunderbird because they made a decision to do so, and people who have
had Thunderbird pre-installed on their machine for some reason (e.g.
because they're in some organization with wise IT people). Making claims
regarding whether people tend to use or not use extensions, whether we
have growth or decline etc. should really be treating those two
categories of users separately - even if we can't place users in these
categories explicitly.

5. Low extension use is at least in part due to our not suggesting
highly-relevant extensions to users:
https://bugzilla.mozilla.org/show_bug.cgi?id=326514
I believe devs should try to put some effort into figuring out whether
various extensions would be relevant on someone's system; and otherwise
at least suggest some statistically-popular ones based on the simpler
and more generic information (like locale, hardware, choice of OS and so
on). That would be especially neat for the "they preinstalled it for me"
crowd, because they would get to actually make some choices, and might
find something they like and excites them.

6. "the 5-10% of users who even install and use add-ons that aren't
Lightning." - that's a bold statement, that seems to contradict even
Christopher's partial numbers. Show your stats on this please.

Eyal

Geoff Lankow

unread,
Oct 3, 2019, 7:22:20 PM10/3/19
to tb-pl...@mozilla.org

DL itself hasn't been updated for over two years, so it's not just your extension that's not had any maintenance. Looked into WebDAV?

GL

Will

unread,
Oct 4, 2019, 2:04:57 PM10/4/19
to tb-pl...@mozilla.org
On 04/10/19 01:22, Geoff Lankow wrote:

DL itself hasn't been updated for over two years, so it's not just your extension that's not had any maintenance. Looked into WebDAV?


The author of DL posted on their list:

"I'm still supporting the DL server though, the command line client as well as the "wx" windows GUI. I'm lagging in terms of available time, but I'm actively using DL for a variety of reasons, so that's not going away."

He has confirmed that to us privately as well. We had been intending to assist in the core code as well... but currently fence sitting on that.

Latest commit a47ff1d on 11 Jul - not that it was anything particularly important, but.

In any event, we have not had any issue with it and we don't see any major Issues logged there.

However, that is all irrelevant to the conversation.

We choose to use DL. It works for both sending attachments to other people, and for sending grants to other people to send us files and a few other handy features.

It is designed for the job, and It just works.

The bit that doesn't is the plugin.

B. Rgds

Axel Grude

unread,
Oct 4, 2019, 9:18:39 PM10/4/19
to tb-planning

I absolutely agree 100% with everything Jörg said. I think I would have somehow liked to express this, and that's exactly why we need a show an tell for Add-on authors, so show / explain to core developers what we do with our Add-ons. I think just relying on one of them discovering and using one of our Add-ons gives us only a very slim chance to be regarded.

Also, at the moment I would not know how to convert most of the things I do into APIs... I use a lot of XPCOM functionality (I think up to 50 different XPCOM interfaces, for some only one or two functions others absoultely deep diving), so the question is, what of this can be "safely" exposed to a web extension?

This was also one of the reasons why I thought " if it is unsafe for an Add-on to use XPCOM why is it safe for Thunderbird JavaScript core code?".

As a Core Developer, please ask yourself: if the Thunderbird "Scripted layer" was forced to go through an API (not allowed to use XPCOM idls anymore), would you design it differently?

Axel


Axel Grude
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:Jörg Knobloch <jo...@jorgk.com>
To:<tb-pl...@mozilla.org>
Sent: Thursday, 10/3/2019, 22:42 22:42 IST +0100 [Week 40]

ISHIKAWA,chiaki

unread,
Oct 5, 2019, 3:45:05 AM10/5/19
to tb-pl...@mozilla.org
I see.

I thought the conversion in step (3) is not quite mechanical after
seeing the changes done for tests of calendar.
Is there a tool to help someone who converts the test js files?

TIA

Chiaki

Onno Ekker

unread,
Oct 5, 2019, 6:37:57 AM10/5/19
to tb-pl...@mozilla.org
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.

 -Magnus

Can I have a little more clarification on this?

As an add-on author, I always tried to keep my add-ons working during the daily/beta release cycle.

I think you are telling us add-on developers now too, that it doesn't make much sense in trying to keep our XUL Legacy add-on or bootstrapped add-on compatible with Thunderbird 71.0a1 or later, because it won't work in Thunderbird 72.0a1 or 73.0a1 anyway, let alone in Thunderbird 78.

Is that also what you implied?

Onno

Magnus Melin

unread,
Oct 5, 2019, 7:53:16 AM10/5/19
to tb-pl...@mozilla.org
On 05-10-2019 13:37, Onno Ekker wrote:
>>
>>
> Can I have a little more clarification on this?
>
> As an add-on author, I always tried to keep my add-ons working during
> the daily/beta release cycle.
>
> I think you are telling us add-on developers now too, that it doesn't
> make much sense in trying to keep our XUL Legacy add-on or
> bootstrapped add-on compatible with Thunderbird 71.0a1 or later,
> because it won't work in Thunderbird 72.0a1 or 73.0a1 anyway, let
> alone in Thunderbird 78.
>
> Is that also what you implied?
>
Yes that is correct. Support for non-WebExtension add-on will be
dropped, so "keeping up" won't help, unless you convert it to a
supported format.

Onno Ekker

unread,
Oct 5, 2019, 11:26:33 AM10/5/19
to tb-pl...@mozilla.org
Op 5-10-2019 om 13:53 schreef Magnus Melin:

> On 05-10-2019 13:37, Onno Ekker wrote:
>>>
>>>
>> Can I have a little more clarification on this?
>>
>> As an add-on author, I always tried to keep my add-ons working during
>> the daily/beta release cycle.
>>
>> I think you are telling us add-on developers now too, that it doesn't
>> make much sense in trying to keep our XUL Legacy add-on or
>> bootstrapped add-on compatible with Thunderbird 71.0a1 or later,
>> because it won't work in Thunderbird 72.0a1 or 73.0a1 anyway, let
>> alone in Thunderbird 78.
>>
>> Is that also what you implied?
>>
> Yes that is correct. Support for non-WebExtension add-on will be
> dropped, so "keeping up" won't help, unless you convert it to a
> supported format.
>
>  -Magnus


And do you think SeaMonkey will follow suit(e)?

I mean, they share your infrastructure, so they can't keep using
addons.thunderbird.net.

And maybe there will ever be a SeaMonkey 2.57 or SeaMonkey 2.65, which
will hopefully support the same add-ons as Thunderbird 60 and 68 does.
But they can also stay on 2.49 and keep backporting security patches,
but then they must probably do the same for a future
addons.seamonkey-project.org or something like that...

Onno

Walter L Schwartz

unread,
Oct 5, 2019, 11:48:41 AM10/5/19
to tb-pl...@mozilla.org

You can follow along with the plans for SeaMonkey Extension Compatibility Tracking.

Juergen Fenn

unread,
Oct 5, 2019, 1:04:22 PM10/5/19
to tb-pl...@mozilla.org

Am 02.10.19 um 20:55 Uhr schrieb Jörg Knobloch:


>>
>> So for us, 52.x with a couple of extensions does exactly what we want,
>> which is more than can be said for your shiny new things.
>
> Just as a matter of interest: Which ones are so important and not
> updated since TB 52?


Manually sort folders isn't. Several developers have tried for weeks on
Github to update to TB 68, to no avail. And that's a real showstopper
for me to upgrade to a version 60+.

Regards,
Jürgen.

Richard LEGER

unread,
Oct 5, 2019, 1:04:30 PM10/5/19
to tb-pl...@mozilla.org
On Sat, Oct 5, 2019 at 8:45 AM <tb-planni...@mozilla.org> wrote:

Date: Fri, 4 Oct 2019 16:14:41 +0200
From: Will <wi...@impamark.co.uk>
To: tb-pl...@mozilla.org

Subject: Re: Intent to de-support: traditional add-ons

On 04/10/19 01:22, Geoff Lankow wrote:
>
> DL itself hasn't been updated for over two years, so it's not just
> your extension that's not had any maintenance. Looked into WebDAV?
>

The author of DL posted on their list:

"I'm still supporting the DL server though, the command line client as
well as the "wx" windows GUI. I'm lagging in terms of available time,
but I'm actively using DL for a variety of reasons, so that's not going
away."  He has confirmed that to us privately as well.

Will, 

Your best way forward would be to get DL Provider for Thunderbird add-on converted to a webextension as suggested by TB Team so you can upgrade to more recent version of Thunderbird and future ones... just from a security point of view that would be advised at some point.

Maybe ask lead developer of the add-on what would it take to migrate it to a mailextension (webextension for Thunderbird) to make it compatible with recent version of TB (e.g 60.8 at the least which is should still be compatible with legacy add-on in theory) and later for the future? 

The first step may be to create a new branch to keep maintaining current legacy add-on code separately on its own... and use the master branch for mailextension conversion and future development... starting by moving it to an upper version number... from 0.xx.x to 1.xx.x... those are just ideas... also a ,xpi file is just a .zip folder containing source code so it can easily be extracted if need be... to access code and look at it...

Perhaps then the thing may be to list:
- what need to be done for the conversion to happen
- how long it would take (and cost if any associated)
- would it require any new Thunderbird webextension APIs (https://thunderbird-webextensions.readthedocs.io/en/latest/) to be developed? There is already a file sharing system implemented in May for attachment so supposedly the required extension shall already exists...

The following from previous post may help as well...

"...
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. 
 
We had been intending to assist in the core code as well... but currently fence sitting on that.

That may be the best way forward, what is blocking you?

If not you directly, you could also try to find a third-party developer that may be willing to help you working on it and send GitHub pull requests to the lead developer that may be in measure to at least review them and possibly merge them into source code and then publish updated version on addons.thunderbird.net (a.k.a. ATN). Both legacy and mailextension version of the add-on shall be able to seat together for now in the same ATN location... from my understanding... may be just a matter of playing with version numbers...

Some people in this mailing list have worked at migrating legacy add-on to mailextension they may be able to provide advise on how to start and proceed...
This may also be of help as starting point as well: https://extensionworkshop.com/documentation/develop/porting-a-legacy-firefox-extension/
 
Latest commit a47ff1d
<https://github.com/DownloadTicketService/dl/commit/a47ff1dd8124a87575188a5dd86889a16ea4f9e0>

on 11 Jul - not that it was anything particularly important, but.

At least it shows that it is still maintained somehow and the lead developer is still merging contribution from others... so that looks promising... just a matter of finding resources and a good will from lead developer (which you seems to have) :-)

In any event, we have not had any issue with it and we don't see any
major Issues logged there.

Well the major issue is compatibility with upper version of TB starting from 60.0
This is where it got to a stale...

Apparently the lead developer and his group are no longer using TB **because** they could not keep up with TB changes and "undocumented" features so their extensions keep breaking :-)

Though as per recent post from June, he may be happy to help if someone wants to contribute or take over the Thunderbird add-on... with or without a financial bounty from my understanding :-)

Some way forward possible then... good luck!

Regards,

Magnus Melin

unread,
Oct 5, 2019, 2:54:01 PM10/5/19
to tb-pl...@mozilla.org
On 05-10-2019 18:26, Onno Ekker wrote:
> And do you think SeaMonkey will follow suit(e)?

SeaMonkey isn't ... doing very well. It's not been possible to actually
start up the UI since around February 2018. As you can understand,
that's game over.

> I mean, they share your infrastructure, so they can't keep using
> addons.thunderbird.net.
>
> And maybe there will ever be a SeaMonkey 2.57 or SeaMonkey 2.65, which
> will hopefully support the same add-ons as Thunderbird 60 and 68 does.
> But they can also stay on 2.49 and keep backporting security patches,
> but then they must probably do the same for a future
> addons.seamonkey-project.org or something like that...

Keep? They haven't been able to release something even based on the 60
ESR code yet. When the 60 series reaches end of life in 2-3 weeks, they
are 2 full ESR cycles after away from releasing anything without
security holes.

 -Magnus

Wayne Mery

unread,
Oct 5, 2019, 6:13:03 PM10/5/19
to Thunderbird planning (moderated), Juergen Fenn
On 10/5/2019 11:55 AM, Juergen Fenn wrote:

Am 02.10.19 um 20:55 Uhr schrieb Jörg Knobloch:
So for us, 52.x with a couple of extensions does exactly what we want,
which is more than can be said for your shiny new things.
Just as a matter of interest: Which ones are so important and not
updated since TB 52?

Manually sort folders isn't. Several developers have tried for weeks on
Github to update to TB 68, to no avail. And that's a real showstopper
for me to upgrade to a version 60+.

Regards,
Jürgen.
I'm not a user of the add-on myself, but the version from about a week ago https://addons.thunderbird.net/en-US/thunderbird/addon/manually-sort-folders/ seems to work

Juergen Fenn

unread,
Oct 5, 2019, 9:56:50 PM10/5/19
to Thunderbird planning (moderated)

Am 06.10.19 um 00:12 Uhr schrieb Wayne Mery:


> I'm not a user of the add-on myself, but the version from about a week
> ago
> https://addons.thunderbird.net/en-US/thunderbird/addon/manually-sort-folders/
> seems to work


Not exactly, there still are bug reports coming in, cf.

https://github.com/protz/Manually-Sort-Folders/issues/92#issuecomment-538033138
https://github.com/protz/Manually-Sort-Folders/issues/99
https://github.com/protz/Manually-Sort-Folders/issues/93

Sorting accounts and folders really should be part of core. We should
not rely on an add-on for this.

Matt Harris

unread,
Oct 5, 2019, 10:06:24 PM10/5/19
to tb-pl...@mozilla.org
On 06-Oct-19 11:04 AM, Juergen Fenn wrote:

Am 06.10.19 um 00:12 Uhr schrieb Wayne Mery:
I'm not a user of the add-on myself, but the version from about a week
ago
https://addons.thunderbird.net/en-US/thunderbird/addon/manually-sort-folders/
seems to work

Not exactly, there still are bug reports coming in, cf.

https://github.com/protz/Manually-Sort-Folders/issues/92#issuecomment-538033138
https://github.com/protz/Manually-Sort-Folders/issues/99
https://github.com/protz/Manually-Sort-Folders/issues/93

Sorting accounts and folders really should be part of core. We should
not rely on an add-on for this.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1584861
Looks like the add-on does a little more than advertised.

Matt

Wayne Mery

unread,
Oct 5, 2019, 10:26:59 PM10/5/19
to Thunderbird planning (moderated)
Did you test any of these issues?

On 10/5/2019 8:34 PM, Juergen Fenn wrote:
Am 06.10.19 um 00:12 Uhr schrieb Wayne Mery:
I'm not a user of the add-on myself, but the version from about a week
ago
https://addons.thunderbird.net/en-US/thunderbird/addon/manually-sort-folders/
seems to work

Not exactly, there still are bug reports coming in, cf.

https://github.com/protz/Manually-Sort-Folders/issues/92#issuecomment-538033138
True. But not the primary purpose of the add-on?
https://github.com/protz/Manually-Sort-Folders/issues/99

cosmetic - the add-ons settings does exist under tools

https://github.com/protz/Manually-Sort-Folders/issues/93

Perhaps I misunderstand the issue, but I cannot reproduce this on 64bit Windows 68.1.1. 

There appear to be multiple contributors to this addon and the primary author is quite capable.  I have little doubt most of the important issues will be addressed.

Juergen Fenn

unread,
Oct 6, 2019, 10:14:41 AM10/6/19
to tb-pl...@mozilla.org

Am 06.10.19 um 04:26 Uhr schrieb Wayne Mery:


> Did you test any of these issues?


No, Wayne, I didn't because I usually wait with such major upgrades
until there are no more bug reports, and I could not find any
confirmation so far which said that the new version of the add-on works
as it did before. I've been following Github, this mailinglist and the
German TB newsgroup in de.* for weeks.

But I am glad to say that you are right. I did a backup of both the
binaries and my profile folder and tested the new version of Manually
sort folders from ATN, and indeed it does work alright for me.

So, thank you for inviting me to a test at this time.

However, I am running TB 68.1.1 on macOS 10.13.6, and I realise that TB
now needs up to 500 MB of RAM (some 300 when typing this mail, up to 500
when I also start chat and newsgroups) which looks way too much compared
to earlier versions. I would very much appreciate if you please could
look into this. It used to be some 150 to 200 MB of RAM.

And, of course, again I would like to say that sorting accounts and
folders freely should please become a part or TB core.

BTW, I like the feel of TB 68 on the Mac. Everything seems to run more
smoothly, and it feels good that Thunderbird settings look more like a
recent Firefox now. Thanks for that!

ace

unread,
Oct 6, 2019, 10:46:02 AM10/6/19
to Thunderbird planning (moderated), Juergen Fenn
Dňa 6. 10. 2019 o 13:34 Juergen Fenn napísal(a):

> However, I am running TB 68.1.1 on macOS 10.13.6, and I realise that TB
> now needs up to 500 MB of RAM (some 300 when typing this mail, up to 500
> when I also start chat and newsgroups) which looks way too much compared
> to earlier versions. I would very much appreciate if you please could
> look into this. It used to be some 150 to 200 MB of RAM.

> And, of course, again I would like to say that sorting accounts and
> folders freely should please become a part or TB core.

Sorting folders or accounts seems like an advanced feature where most
users are happy with the alphabetic sorting (like most file managers do
too). Adding such a feature needs a lot of UI for a questionable
benefit. So it would be best if an addon did it first so we could then
evaluate it. See https://bugzilla.mozilla.org/show_bug.cgi?id=1359410
where I offered support for allowing an addon to manage the order of the
accounts. It seems to have stalled there, patch for TB is ready, but the
(already existing) addon update didn't come. So in this case please do
not blame the TB core developers.

> BTW, I like the feel of TB 68 on the Mac. Everything seems to run more
> smoothly, and it feels good that Thunderbird settings look more like a
> recent Firefox now. Thanks for that!

I assume the price for this is the increased RAM usage :) We inherit all
the rendering layers from Firefox. Also I realy doubt the removal of XBL
and XUL elements and replacing them with pure JS duplicates (Custom
Elements) has any positive impact on RAM usage. I'd guess it is more
wasteful.
We haven't added many features in TB that would answer the doubling of
the RAM usage. But sadly we don't have tests that would catch any such
increase.

aceman

Wayne Mery

unread,
Oct 6, 2019, 12:06:09 PM10/6/19
to Thunderbird planning (moderated)
On 10/6/2019 7:34 AM, Juergen Fenn wrote:
However, I am running TB 68.1.1 on macOS 10.13.6, and I realise that TB
now needs up to 500 MB of RAM (some 300 when typing this mail, up to 500
when I also start chat and newsgroups) which looks way too much compared
to earlier versions. I would very much appreciate if you please could
look into this. It used to be some 150 to 200 MB of RAM.

I help manage releases, and also frequently check memory usage on my various machines and often look at Thunderbird's usage. So I can anecdotally state I am not aware of any feature which added significant memory usage as you describe, nor any confirmed bugs along those lines*. 

Generally speaking memory usage in the 200-800 MB range is fine, and it's OK for it to go up and down as usage of functions and features changes. 

* The only two bug reports in the 68 period are these:

Bug 1567545 - 68.0b5: possible memory leak

Bug 1581849 - Thunderbird Daemon lives after closing - Spawns many instances... causing very sluggish response (eats up memory eventually)

Axel Grude

unread,
Oct 6, 2019, 4:00:25 PM10/6/19
to tb-planning

I don't think there is too much benefit of sorting folders, but account order would really be an important feature - usually the most important accounts are the ones that added later (e.g. through decommissioning of mail servers) so  i guess there should be a way to put them (or at least one specific, user elected account) to the top. I regularly get request for a "auto-collapse tree" feature (maybe something similar to the way the folder tree is handled in windows explorer, with not every folder visible / expanded).

Or automatically collapsing recently visited folders that have no unread mails left, I am sure there would be ample scope for improvement without writing a sorting routine. I actually would re-sorting folders counter-productive and difficult to manage, but ideally accounts should be able to be re-sorted in the account manager via drag + drop) . One of the biggest design problems with the folder tree is the fact that one ends up scrolling a lot, and that's exactly the reason why I have stopped using it for navigation and switched to QuickFolders entirely.

Axel

Axel Grude
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:Ace <acel...@atlas.sk>
To:Thunderbird Planning (Moderated) <tb-pl...@mozilla.org>; Juergen Fenn <jf...@gmx.net>
Sent: Sunday, 10/6/2019, 15:45 15:45 IST +0100 [Week 41]

Juergen Fenn

unread,
Oct 6, 2019, 4:54:42 PM10/6/19
to tb-pl...@mozilla.org

Am 06.10.19 um 22:00 Uhr schrieb Axel Grude:


> I don't think there is too much benefit of sorting folders, but account
> order would really be an important feature


Axel, you are absolutely right, the two cannot be separated from one
another and they are indeed both covered by Manually sort folders.

I have five e-mail accounts and 13 local folders in my sidebar in TB. I
cannot imagine to have them displayed in alphabetical order only. So the
feature is indispensable to me, and it seems we are not the only ones.

Also, drag and drop for both accounts and folders indeed would be what
most users expect nowadays.

Regards,
Jürgen.

Juergen Fenn

unread,
Oct 6, 2019, 4:54:51 PM10/6/19
to tb-pl...@mozilla.org

Am 06.10.19 um 18:06 Uhr schrieb Wayne Mery:


> Generally speaking memory usage in the 200-800 MB range is fine, and
> it's OK for it to go up and down as usage of functions and features
> changes. 


The good news is that I cannot reproduce the 500 MB maximum at first
startup. I can confirm that memory use is indeed dynamic, that's fine.

After a restart of TB on my system (MacBook Pro mid 2012, 4 GB RAM,
macOS 10.13.6) TB 68 now requires some 170 MB RAM just after starting.
Usage goes up to some 350 MB when I also start the newsreader and chat
and start typing in the compose editor. I have no idea what caused the
500 MB usage earlier today. I tried starting the webbrowser for
installing new dictionaries, but this does not do it. Lightning is
disabled, as usual.

Anyway, memory usage of TB 60 vs. 68 went up from some 150--200 MB to
200--350 MB dynamically, and there are some 50 MB compressed memory -- I
think this was much less in TB 60.

@aceman: Thanks to you, too, for explaining. I can quite understand that
resources are scarce. But in the case of Manually sort folders, the
add-on ranks forth after Lightning, Import tool folders, and Provider
for Google Calendar. So I think there is a need for that feature which
is a normal part of other mail clients, too. You might like to think
about it again some time.

https://addons.thunderbird.net/de/thunderbird/extensions/?sort=users

Will

unread,
Oct 7, 2019, 5:56:56 AM10/7/19
to tb-pl...@mozilla.org
On 05/10/19 18:20, Richard LEGER wrote:
The author of DL posted on their list:

"I'm still supporting the DL server though, the command line client as
well as the "wx" windows GUI. I'm lagging in terms of available time,
but I'm actively using DL for a variety of reasons, so that's not going
away."  He has confirmed that to us privately as well.


Your best way forward would be to get DL Provider for Thunderbird add-on converted to a webextension as suggested by TB Team so you can upgrade to more recent version of Thunderbird and future ones... just from a security point of view that would be advised at some point.


<bangs head on desk>

I am not sure that you have read my previous posts on the subject have you?



Maybe ask lead developer of the add-on what would it take to migrate it to a mailextension (webextension for Thunderbird) to make it compatible with recent version of TB (e.g 60.8 at the least which is should still be compatible with legacy add-on in theory) and later for the future? 



<bangs head on desk again>

Now I know you have not read any previous messages in the subject.

Been there done that. As per my previous messages.

Simply, he can't for several genuine reasons and, as I have mentioned before, he has apologised to us personally for this, but can't change the circumstances.

And regarding the rest of your comments, thank you, but if you had read my preceding comments you could have saved yourself a lot of time as I have answered them already.


So that no one else wastes any more time telling me to contact the dev, fork code, or whatever:

The dev started to try and modify the plugin for 60 but there were a number of issues - some bits of the API were not finished at that moment in time (as far as I remember)

Lots of time was spent on a couple of TB bugs trying to resolve this (see other posts and bug tracker)

Dev realised that he was going to have to rewrite AGAIN for 68 (and I won't regale you with his assessment of the Filelink API code.... but suffice to say he is less than impressed)

Devs work colleagues dumped TB and moved on to another mail client due to the lack of progress

Dev hoped he would have time to work on the plugin and get it done for 60

Due to changing situations at work he was unable to do so. He could use DL on the command line and with the widget for himself so did not have a pressing need to work on the TB plugin

We spoke to him directly (he contacted us) about paying for it to be upgraded but for personal reasons he can't ( he did explain why but I am not prepared to divulge here)


TL;DR

Dev can't update the plugin
We offered to pay the dev to update it but he can't
We have tried to look for other devs to pay to update it, but can't find one as yet.



We had been intending to assist in the core code as well... but currently fence sitting on that.

That may be the best way forward, what is blocking you?

It doesn't matter if the core code works perfectly if we can't use the plugin.

We are not going to spend time working on it if we aren't using TB and the plugin.

Just economic reality.


Axel Grude

unread,
Oct 7, 2019, 7:22:08 AM10/7/19
to tb-planning

As regards sharing anecdotal memory usage - my main Thunderbird instance is in autostart and I rarely restart it all, currently clocking in at around 450MB (on a 16GByt Ram system) constant,  with a mail profile footprint of around 41.5 Gbyte I think that's perfectly acceptable. It's more important to me that I can quickly go through my email at any time and that the UI doesn't become sluggish. It's currently "lean enough for me" with only 15 active Add-ons installed.


Axel Grude
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:Juergen Fenn <jf...@gmx.net>
To:<tb-pl...@mozilla.org>
Sent: Sunday, 10/6/2019, 19:01 19:01 IST +0100 [Week 41]

Tanstaafl

unread,
Oct 7, 2019, 3:47:45 PM10/7/19
to tb-pl...@mozilla.org
On Sun Oct 06 2019 16:00:16 GMT-0400 (Eastern Standard Time), Axel Grude

<axel....@gmail.com> wrote:
> I don't think there is too much benefit of sorting folders, but account
> order would really be an important feature - usually the most important
> accounts are the ones that added later (e.g. through decommissioning of
> mail servers) so  i guess there should be a way to put them (or at least
> one specific, user elected account) to the top. I regularly get request
> for a "auto-collapse tree" feature (maybe something si