Intent to de-support: traditional add-ons
Magnus Melin
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
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
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
> B) convert your add-on to a Web Extension Experiment
> Most add-ons should be able to be converted to an experiment with a
> reasonable effort. The recommended path is forward is to convert it to
> an a MailExtension though. That will make sure the add-on works without
> significant changes over many years. If you go with option B, you'll
> have to maintain a lot of more code yourself and breakages can and will
> be bad unless you keep up really close. MailExtension Experiments should
> be seen as such, experiments with the goal of getting the API they need
> into Thunderbird core. Please work with us on getting the needed pieces
> in as a supported API. Initially we'll be allowing experiments to be
> exposed to the general public, but over time (years) Thunderbird will
> gravitate towards not having the experiments available to the general
> public, the same way it works for Firefox.
>
> -Magnus
>
>
> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Ftb-planning&data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C0143db32c0774fe0fad308d7466faa18%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637055318541359930&sdata=u0yzGYuTouWKgMHvMrUGUQlsP6QDjIQG%2FiwZu1tPFhM%3D&reserved=0
>
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
John Bieling
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
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:
>>>
>>> B) convert your add-on to a Web Extension Experiment
>>>
>>> Most add-ons should be able to be converted to an experiment with a
>>> reasonable effort. The recommended path is forward is to convert it to
>>> an a MailExtension though. That will make sure the add-on works without
>>> significant changes over many years. If you go with option B, you'll
>>> have to maintain a lot of more code yourself and breakages can and will
>>> be bad unless you keep up really close. MailExtension Experiments should
>>> be seen as such, experiments with the goal of getting the API they need
>>> into Thunderbird core. Please work with us on getting the needed pieces
>>> in as a supported API. Initially we'll be allowing experiments to be
>>> exposed to the general public, but over time (years) Thunderbird will
>>> gravitate towards not having the experiments available to the general
>>> public, the same way it works for Firefox.
>>>
>>> -Magnus
>>>
>>>
>>> _______________________________________________
>>> tb-planning mailing list
>>> tb-pl...@mozilla.org
>>>
>>>
>> _______________________________________________
>> tb-planning mailing list
>> tb-pl...@mozilla.org
>>
> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org
Emmanuel SELLIER
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
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
Is this announcement going to be posted to https://thunderbird.topicbox.com/groups/addons
and https://discourse.mozilla.org/c/thunderbird/addons?
Magnus Melin
> 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
Magnus Melin
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
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
Patrick Brunschwig
> 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.
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
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
>
> 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.
>
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
> 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 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.
updated since TB 52?
Jörg.
Geoff Lankow
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
> 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.
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
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
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/74https://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
> 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
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
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
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
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
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
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
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
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ć
Eyal Rozenberg
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
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
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?
"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.
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
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
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
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
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
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
>>
>>
> 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?
>
dropped, so "keeping up" won't help, unless you convert it to a
supported format.
Onno Ekker
> 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
You can follow along with the plans for SeaMonkey
Extension Compatibility Tracking.
Juergen Fenn
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
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.
routes: A) convert your add-on to a MailExtension. If the API you need
doesn't exist yet, tell us about it
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.
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.
In any event, we have not had any issue with it and we don't see any
major Issues logged there.
Magnus Melin
> 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
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.
Juergen Fenn
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
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 workNot 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.
Looks like the add-on does a little more than advertised.
Matt
Wayne Mery
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 workNot 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
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
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
> 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
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:
Axel Grude
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
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
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
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
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
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?
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?
We are not going to spend time working on it if we aren't using TB and the plugin.
Just economic reality.
Axel Grude
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.
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
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
<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 similar to the way
> the folder tree is handled in windows explorer, with not every folder
> visible / expanded).
I'll take this opportunity to plug a bug/feature enhancement 'favorite'
of mine:
Allow 'Pinning' (and re-ordering) one or more 'Folder Views' to the top
of the Folder Pane
bug 1163555 - https://bugzilla.mozilla.org/show_bug.cgi?id=1163555
Basically, having a 'Favorites' list above the Accounts list, where you
can drag/create 'shortcuts' to your ... 'favorite' folders.
Axel Grude
I am personally not a fan of vertical only navigation,
it's really straining on the wrist. Why not have a favorites
toolbar instead? (well that's pretty much what
QuickFolders is) that's multidimensional navigation, which is
much easier to do than going through a vertical list...
Axel
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
Subject:Re: Intent to de-support: traditional add-ons
From:Tanstaafl <tans...@libertytrek.org>
To:<tb-pl...@mozilla.org>
Sent: Monday, 10/7/2019, 19:15 19:15 IST +0100 [Week 41]
Graeme
I managed to make my addon work with MailExtension Experiments
which was largely using the bootstrapped version and turning the
bits I needed into experiment APIs.
But this email and others I have read tell me that I'm going to
have to eventually move into a MailExtensions addon and I really
don't know that there is anything that I've seen that goes beyond
a Hello World example. I looked at a number of pages mentioned on
these emails and found all the broken or non existant links. I
found the list of APIs that looks impressive but I don't think is
any longer in the area of composition than it was months ago. I'm
sure they are very helpful for those who understand them but, for
me, they may as well be in Chinese.
What I'd really like is a number of working addons that I can look at and get ideas from.
I looked at the Addons that are available and was very
surprised to see how many of the featured addons are
still legacy. They require restart. I wish there was a place or a
list of the working MailExtension Addons.
I realise that all the people who know what they are doing are very busy maintaining legacy addons and keeping up with Firefox changes etc. I hope that once legacy addons are dropped there will be more time for documentation that can help those of us that have survived as MailExtension Experiments.
Blessings
Graeme
Tanstaafl
> I am personally not a fan of /*vertical only navigation*/, it's really
> straining on the wrist. Why not have a /*favorites toolbar*/ instead?
> navigation, which is much easier to do than going through a vertical
> list...
imo, I see no reason you couldn't use both simultaneously... I use and
love Quickfolders, but I still really, really want the Favorites/Pinning
capability.
But one major reason this is important - Users coming from Outlook. This
is the first and a major reason our Users preferred Outlook. Whether or
not you agree/prefer a toolbar, if we want to grow our user base, we
have to listen to reasons why people reject TB in favor of Outlook.
I'm not saying we make it an Outlook clone, I'm saying we look at
Outlook features that users want and make sense, and not only implement
them - implement them *better*, make it more flexible, like my idea of
combining the Favorites with the Folderpane toolbar so they work
together - although the Folderpane Toolbar definitely need to be
configurable (add custom/remove items, reorganize them, etc).
Magnus Melin
A few clarifications:
The changes are for the general public only going to come into
effect in the next ESR release, Thunderbird 78 in mid 2020. For
developers, in beta and nightly support will start to disappear
from core once we're ready do so, probably during 2019. Some
notable things that will be removed are the custom overlay loader
(Overlays.jsm), and support for add-ons requiring restart.
For add-on authors going forwards, there is of course also an
option C (depending on what the add-on does): work with us to
integrate the functionality into core. If the add-on is under the
bug-fix category this is certainly the way to go as no API for a
bug-fix would be in sight. In general we're happy to include
functionality provided it's of general usefulness.
MailExtension Experiments is one way to go (and that's not deprecated), but should not be seen as a long term solution. It may be a short term solution though. It means you need to follow changes closely and things will often break. Sometimes in ways that could be hard to solve. They simply need to be understood to be seen as experiments, with no warranties.
-Magnus
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:
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.
- Lightning: to be integrated into the code base
- Mozmill (used in our test infra): we're converting over to using mochitests instead
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
alta88
On 10/15/2019 04:19 AM, Magnus Melin wrote:
>
> For add-on authors going forwards, there is of course also an option C
> (depending on what the add-on does): work with us to integrate the
> functionality into core. If the add-on is under the bug-fix category
> this is certainly the way to go as no API for a bug-fix would be in
> sight. In general we're happy to include functionality provided it's
> of general usefulness.
>
would create bugfix extensions.
Now, however, what possible motivation would there be for a volunteer to
fix bugs that paid staff can't fix or won't fix or even caused. Maybe
there will be a one-off or a junior person needing something for a first
CV. Unless the Council intends to implement paid bug bounties this is
wishful thinking. Worse, it's fundamentally unfair.
It takes a very skilled manager to get free work. Good luck.
By the way, I seriously hope people like Matt and others doing user
support are in a budget, if they want.
Axel Grude
Dear Magnus,
or add-on authors going forwards, there is of course also an option C (depending on what the add-on does): work with us to integrate the functionality into core.
I actually thought about this myself - if it means not losing
the "privileged access" to the JavaScript / XPCOM layer it may
mean a lot less work than constantly adapting an Add-on. There
is only one problem - over the 10 years I am working4 on this
project I have managed to turn it into a paid / self-employed
thing, and with the amount of work ahead and to maintain the
functionality, the only way to recoup would be to turn into a
Thunderbird employee.
I am not sure if that's the correct way forward for me - would
it possible to imagine a specialized / subcontractor position
for an Add-ons developer so they can focus on just that specific
work / functionality, rather than being deployed into stuff we
may not be interested in?
The other argument against core is that only a small group of
users may be interested in the functionality of these legacy
extensions, and by rights they should be the
ones funding that. A "Thunderbird advanced" / freemium model
might be a way out here. Just brain storming...
Axel
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
Subject:Re: Intent to de-support: traditional add-ons
From:Magnus Melin <mkmelin...@iki.fi>
To:<tb-pl...@mozilla.org>
Sent: Tuesday, 10/15/2019, 11:19 11:19 IST +0100 [Week 42]
Eyal Rozenberg
> For add-on authors going forwards, there is of course also an option C
> (depending on what the add-on does): work with us to integrate the
> functionality into core. If the add-on is under the bug-fix category
> this is certainly the way to go as no API for a bug-fix would be in
> sight. In general we're happy to include functionality provided it's of
> general usefulness.
up on Thunderbird's extensibility, either immediately or within a short
period of time. With no force pulling in favor of access to
Thunderbird's innards from overlaid JS code - I'm willing to bet that
would disappear pretty quickly. It's sort of a "divide and conquer"
strategy.
On 16/10/2019 15:03, Axel Grude wrote:
> I am not sure if that's the correct way forward for me - would it
possible to imagine a specialized / subcontractor position for an
Add-ons developer so they can focus on just that specific work /
functionality, rather than being deployed into stuff we may not be
interested in?
yourself in that position - what would you tell other extension
developers when we get locked out of relevant functionality?
Eyal
Magnus Melin
For add-on authors going forwards, there is of course also an option C (depending on what the add-on does): work with us to integrate the functionality into core. If the add-on is under the bug-fix category this is certainly the way to go as no API for a bug-fix would be in sight. In general we're happy to include functionality provided it's of general usefulness.
With respect - if this were to happen, it would essentially mean giving up on Thunderbird's extensibility, either immediately or within a short period of time. With no force pulling in favor of access to Thunderbird's innards from overlaid JS code - I'm willing to bet that would disappear pretty quickly. It's sort of a "divide and conquer" strategy.
Sorry if that wasn't clear, but of course part of this is loosing extensibility. You can't really have full extensibility in the traditional way, except for as experiments.
Why would Thunderbird create an API for a useful thing *only* for add-ons? If it's of general usefulness, it would be exposed in the core application. This doesn't mean core should have everything: there's still room for add-ons to cater for specialized use cases.
-Magnus
Magnus Melin
I don't see how that would work... for that case it seems more reasonable to keep developing it as an add-on (experiment or not) and make sure the add-on users are paying or donating enough to the add-on to keep development of it sustainable.
-Magnus
Andrei Hajdukewycz
On 10/3/2019 12:35 PM, Eyal Rozenberg wrote:
All versions of Thunderbird ping ATN, because requests to the old AMO domains are redirected to us. We even get pings from a few stragglers on versions in the single digits.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.
You can find global Thunderbird statistics on stats.thunderbird.net - in particular, the percentage of users on each version. There are roughly 1.5% of users on versions 38 and below. 2.5% on 45.*, and 3.5% on 52.*. Plus maybe 0.5% on random older betas, mostly 56 because of a weird auto update rule. In total, 8% on "old versions"(prior to 60). While quite low overall, It's higher than we would like, but a bit lower(~6.5%) on weekends, probably due to users stuck on employer-installed versions.
Nothing has happened over the last few months, as you can see. Extension support is not significant to most users. Seasonal variations like summer European vacations, Christmas, and Easter have more effect on Thunderbird user numbers than any change to extension support ever could. Users did not significantly change during last's year's TB60 addonpocalypse either, so I wouldn't expect any huge difference when 68 auto updates go out.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?
Sure, I agree with you. The context here is not "should we support extensions or not?" it's - how much work do we put into supporting them. We already put in a lot of work, arguably more than the return on investment. Add-on developers aren't poorly supported. Add-ons occupy a massive amount of work and discussion time from Thunderbird employees. If I had to make a wild guesstimate based on my time, Geoff's time, Magnus' time, etc, I would say that add-ons consume somewhere around 30% of our overall developer time. Magnus could probably give you a better estimate. I know I spend roughly 50% of my time working on add-on related issues and support. Regardless of the specific number, it is quite a bit.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.
You interpret the substantial support that add-on developers receive as insufficient, not realizing that it's almost more than we can afford already.
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,
True, but irrelevant. Add-ons have never, and will never drive user growth. They may help in small ways with user retention.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.
In what way does it contradict them? Keep in mind that user counts for each add-on count the same users many times, because you are counted repeatedly for each add-on you have installed.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
Even assuming the overall average is 2 add-ons per user, if you sum the add-ons that aren't Lightning you get 3.2M daily users, divided by 2 for multiple counts, which would be ~16%.
However, users are heavily concentrated in the top 10-20 add-ons, many of which either should be redundant with core, or part of core in some way(ImportExportTools, Provider, Manually Sort Folders) or are already on their way to core(Enigmail). If you sum outside of the top 10, there's 1.78M add-on users, again divided by 2 to account for multiple users, and you're already below 10%. Provider and ImportExportTools together account for 23% of all add-on users by themselves.
I do suspect that this guess overstates the number of individual users, because I think the average is higher than 2. Calculating statistics on number of users that have an add-on installed is possible, but it requires setting up some new logging and querying/compiling of those statistics. I have added it to my list of tasks, you can track when this work is completed in this issue on GitHub.
Andrei Hajdukewycz
> Also, I suspect there's quite a bit of under-counting going on. It
> seems strange that so many extension authors continue to update their
> extensions despite supposedly having no users. And that numerous
> extensions have dozens of daily downloads despite having no users at
> all, or a number of users under half an order of magnitude of the
> daily downloads. I wonder whether some of it isn't a
> "use-and-disable-when-done" pattern.
Downloads aren't counted, there is no download data on ATN. But sure,
suspect all you like. You haven't done any work to support any of your
assertions or assumptions.
>
> These two sentences are an example of the myopia I was talking about.
> Take my less-popular extension for example: BiDi Mail UI. It is all
> but necessary if you want to read or write email in a right-to-left
> language. But - it's only the 103'rd most popular extension. Why?
> Because the vast majority of people in Arabic, Farsi, Urdu and
> Hebrew-speaking countries simply do not know about Thunderbird. They
> haven't tried it, haven't heard of it. (And yes, computer use is
> significantly lower in those countries on average than in Europe and
> the US, but not as low as some might think.)
>
> So add-ons do and will drive user base growth in countries using these
> languages. Which means among 400 Million people or so. That is, when
> growth is not prevented by other factors.
>
> Now, mine is just one example - I'm sure there are others.
Um, this doesn't make any sense. Your add-on hasn't driven any growth,
and it's not likely to in the future. Sure, it might be a feature that
users from those areas would want, if they started using Thunderbird,
but that's got nothing at all to do with the add-on driving growth.
Honestly, the fact that you call this 'myopic' leads me to believe that
I am wasting my breath here.
>
>
> That's an unacceptable argument.
>
> If that's true, then stop wasting your time and ours with this wild
> goose chase of extension maintenance.
OK, you've convinced me. It is not worth engaging with you or other
add-on authors with your type of attitude anymore. That is my (personal)
stance going forward. Sorry. It's simply not worth the time.
Eyal Rozenberg
On 01/11/2019 23:56, Andrei Hajdukewycz wrote:
>> 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.
> True, but irrelevant.
where they didn't choose to install it (which is a guess, but
considering the weekend installations drop, is perhaps not completely
bogus) - the statistics for extension use should possibly be measured
for the other 50% ("weekend installations"), which are almost entirely
people who installed voluntarily. Which means that, except for
lightning, extension used is double. Of course my numbers are not sound,
I was just demonstrating the principle.
>> 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
>>
> In what way does it contradict them? > Keep in mind that user counts for
> each add-on count the same users many times, because you are counted
> repeatedly for each add-on you have installed.
>
> Even assuming the overall average is 2 add-ons per user, if you sum the
> add-ons that aren't Lightning you get 3.2M daily users, divided by 2 for
> multiple counts, which would be ~16%.
times". Not to mention the fact that some people install an extension,
use it, then disable it when they don't use it (like my removedupes).
Also, I suspect there's quite a bit of under-counting going on. It seems
strange that so many extension authors continue to update their
extensions despite supposedly having no users. And that numerous
extensions have dozens of daily downloads despite having no users at
all, or a number of users under half an order of magnitude of the daily
downloads. I wonder whether some of it isn't a
"use-and-disable-when-done" pattern.
> small ways with user retention.
>
Take my less-popular extension for example: BiDi Mail UI. It is all but
necessary if you want to read or write email in a right-to-left
language. But - it's only the 103'rd most popular extension. Why?
Because the vast majority of people in Arabic, Farsi, Urdu and
Hebrew-speaking countries simply do not know about Thunderbird. They
haven't tried it, haven't heard of it. (And yes, computer use is
significantly lower in those countries on average than in Europe and the
US, but not as low as some might think.)
So add-ons do and will drive user base growth in countries using these
languages. Which means among 400 Million people or so. That is, when
growth is not prevented by other factors.
Now, mine is just one example - I'm sure there are others.
> of which either should be redundant with core, or part of core in some
> way(ImportExportTools, Provider, Manually Sort Folders) or are already
> on their way to core(Enigmail).
> If you sum outside of the top 10,
> there's 1.78M add-on users, again divided by 2 to account for multiple
> users, and you're already below 10%. Provider and ImportExportTools
> together account for 23% of all add-on users by themselves.
core you have less need of those add-ons. But if this divide-and-conquer
strategy is what's going to be adopted, then the result will not be
Thunderbird, but - a non-extensible mail client. Extension developers
care about TB because it's extensible; these kinds of choices (couple
with this rationale) suggest the direction is just that.
If that's true, then stop wasting your time and ours with this wild
goose chase of extension maintenance.
Jörg Knobloch
> Sure, I agree with you. The context here is not "should we support
> extensions or not?" it's - how much work do we put into supporting
> them. We already put in a lot of work, arguably more than the return
> on investment.
I don't think so and the "return on investment" part is totally unproven.
You seem to forget one fact that is of utmost importance:
The pillars of the community, power-users, add-on authors, ,
contributors, developers and I'd also say donors, all use use add-ons.
You cut out that (user) group and you will kill the project.
Please generate some statistics to prove or disprove this. Let's have
some statistics that prove that add-on support and donations are
unrelated. That's the *only* statistic that counts. Whether my mother
who uses no add-ons uses Thunderbird or not, with all due respect, does
not change the project way, shape or form. She could be using KMail or
whatever else is available on her platform.
Our product with its bazillion functions relies on non-run-of-the-mill
people who use those functions in many weird and wonderful ways, and
extensibility through add-ons is part of that culture.
So far the argument seems like: The tissue that connects the retina to
the brain is only 0.1% of the total body mass, so it's negligible, let's
remove it. You've just blinded the patient :-(
Jörg.
Ryan Sipes
Hey all,
I think it's good to bring down the temperature on this conversation a little bit. We are not going to stop supporting add-ons - and there is probably a case to be made for putting additional resources into helping add-on authors while they transition to a MailExtension/WebExtension world.
One thing I would like to remind everyone who participates in these discussions is that our community participation guidelines state that while we can disagree vehemently - we should do so whilst being respectful of the people we disagree with. Having spoken with a ton of add-on authors and the people tasked with supporting add-ons working on Thunderbird core, both sides have a really hard time appreciating the burden on the other.
I'm pledging, and I know other folks in the project have voiced
their support for finding a way to provide more resources for
add-on developers. We will get this done, in the meantime we
should refrain from attacking each other and come up with where we
can work together to do the most good.
Will
> Extension support is not significant to most users. Seasonal
> variations like summer European vacations, Christmas, and Easter have
> more effect on Thunderbird user numbers than any change to extension
> support ever could. Users did not significantly change during last's
> year's TB60 addonpocalypse either, so I wouldn't expect any huge
> difference when 68 auto updates go out.
You can't really say that when:
a) forced auto updates are followed by immediate removal of old packages
to prevent downgrades
b) you know that most users are used to being bullied with
update/upgrades even if they don't want them and just put up with it
c) It isn't that easy to find anywhere to complain, or anyone to
complain too..... and even if you do you are usually told 'we think it
is great therefore you must' - which we have seen here far too often.
You argument may have held a bit more water if people were given a free
choice on upgrading, but as it is your reasoning is totally flawed.
Please stop using it.
Paul Morris
Currently, we expect that Thunderbird 74 (the next major beta
version) will no longer support traditional add-ons, and only
support add-ons built with MailExtensions (aka WebExtensions) and
WebExtension Experiments. Thunderbird 74 will be released soon
after Firefox 73 is released on February 11th.
The initial announcement (below) estimated that support would go away by the end of 2019. Thunderbird's Mozmill tests have now been converted to Mochitests, and the Lightning calendar add-on should be integrated into Thunderbird very soon. So I wanted to send out this quick update now that we have a better sense of the timing.
For more details about MailExtensions/WebExtensions addons, see:
https://developer.thunderbird.net/add-ons/about-add-ons
https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html
More details are below in the initial announcement to the
tb-planning mailing list.
-Paul
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:
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.
- Lightning: to be integrated into the code base
- Mozmill (used in our test infra): we're converting over to using mochitests instead
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
_______________________________________________ tb-planning mailing list tb-pl...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
-- Paul Morris Thunderbird.net
Jörg Knobloch
> Currently, we expect that Thunderbird 74 (the next major beta version)
> will no longer support traditional add-ons, and only support add-ons
> built with MailExtensions (aka WebExtensions) and WebExtension
> Experiments. Thunderbird 74 will be released soon after Firefox 73 is
> released on February 11th.
Thanks for the update.
What's the technical reason for de-supporting restartless
traditional/legacy add-ons? Simplification of the code base?
Simplifications at ATN?
I can understand that you want to de-support legacy XUL add-ons that use
TB's own overlay loader since Lightning will no longer require it.
Basically you will terminate almost all add-ons with TB 74, and that
doesn't sound like a gradual transition.
Jörg.
neandr
Jörg wrote:
Basically you will terminate almost all add-ons with TB 74, and that doesn't sound like a gradual transition.
Yes, fully agree.
What about security upgrades for TB60 and TB68?
There are requests from users to stay with TB60, but there are also security concerns they mention.
Do users get an official TB statement about the availability of security upgrades for TB60 and TB68? And how long will they be available? (I think it is more than necessary!)
Guenter
On 01/02/2020 03:49, Paul Morris wrote:
Currently, we expect that Thunderbird 74 (the next major beta version) will no longer support traditional add-ons, and only support add-ons built with MailExtensions (aka WebExtensions) and WebExtension Experiments. Thunderbird 74 will be released soon after Firefox 73 is released on February 11th.
Thanks for the update.
...
Mark Banner
> On 01/02/2020 03:49, Paul Morris wrote:
>> Currently, we expect that Thunderbird 74 (the next major beta
>> version) will no longer support traditional add-ons, and only support
>> add-ons built with MailExtensions (aka WebExtensions) and
>> WebExtension Experiments. Thunderbird 74 will be released soon after
>> Firefox 73 is released on February 11th.
>
> Thanks for the update.
>
> What's the technical reason for de-supporting restartless
> traditional/legacy add-ons? Simplification of the code base?
> Simplifications at ATN?
If I understood my discussions at the Mozilla all-hands this week
correctly (which just happened to briefly touch the subject), the
toolkit add-on manager has now removed the legacy support for add-ons -
or at least disabled it, and are intending to remove the code associated
with it soon. There is a lot of complexity in the add-on manager today,
and starting to remove the legacy code has great maintainability and
development advantages.
They have already had to keep this around longer than they wanted to. I
also suspect that it is just not viable for Thunderbird to maintain a
fork given the extra, likely significant work that would be required to
keep the old code running and match it to the newer code (or fear
another big "jump" later).
> I can understand that you want to de-support legacy XUL add-ons that
> use TB's own overlay loader since Lightning will no longer require it.
>
> Basically you will terminate almost all add-ons with TB 74, and that
> doesn't sound like a gradual transition.
iirc WebExtensions were first introduced with 60. The main push to
WebExtensions came in 68, with the legacy turn-off now happening for
release users in 78.
Given that they are all about a year apart, that feels like a gradual
transition to me.
I recognise this is big transition for add-ons. I'm still working on
transitioning Conversations to be non-legacy WebExtension. Some parts
are done, but there's significant parts left, and Conversations does a
lot of monkey-patching and other things that I'm also simplifying and
rewriting to hopefully make it work.
Mark
Mark Banner
> Jörg wrote:
>
>> Basically you will terminate almost all add-ons with TB 74, and that
>> doesn't sound like a gradual transition.
> Yes, fully agree.
> If upgrading to TB74 brings the end-of-life for most addons, then a
> recommendation to addon users would be to stick with what they have --
> some with TB60 (like Reminderfox), others with TB68 -- a viable way to
> go... until the authors have had time to upgrade?
> What about security upgrades for TB60 and TB68?
>
> There are requests from users to stay with TB60, but there are also
> security concerns they mention.
>
> Do users get an official TB statement about the availability of
> security upgrades for TB60 and TB68? And how long will they be
> available? (I think it is more than necessary!)
If I remember correctly from an earlier discussion, the percentage of
users that use add-ons is probably quite small. Whilst we don't
necessarily want to abandon them, I think that should be taken into
consideration
Is it really worth the additional, possibly complicated work to backport
gecko security fixes to 60 and 68? In some cases it might not even be
possible due to architecture changes. Gecko won't be backporting them
after the ESRs are no longer supported, so we would need to do that,
with people who may not be so familiar with that code.
Mark
Mark Banner
On 02/02/2020 20:11, Eyal Rozenberg wrote:
with the legacy turn-off now happening for
release users in 78.
Didn't Magnus Melin say 74?
I purposely said release users. Paul's comment was about 74 beta which won't go to users.
The next
ESR branch from which Thunderbird will be based is 78 and
won't ship until late June at the earliest.
Mark
Jacques Angevelle
I don't think users of add-ons are so few. There is no way to tell
developers "I need that add-on and will switch from TB to anything else
if there is no hope add-ons I rely on come back".
Perhaps a "vote" related to disabled add-ons show be useful in order to
give priorities. For some add-ons, integrating in core should perhaps
the simplest way to revive them (I think that add-ons like "ask master
password at start-up" are not optimum out of core and integration should
be discussed).
Jacques
Axel Grude
Dear Eyal Rozenberg,
well hopefully it will be not already in June - I don't see all the XUL parts of Tb rewritten in HTML until then (one thing I am worried about is the HTML drag + drop API for mails / folders once nsDragAndDrop is decomissioned), never mind having enough APIs to support the main XPCOM interfaces we need to replace - shouldn't the 68 ESR period be at least a full year?
My hope is that it won't be released until October /
November.
Axel
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips
Subject:Re: Current timeline for de-supporting traditional add-ons
From:Eyal Rozenberg <eya...@technion.ac.il>
To:Mark Banner <mba...@mozilla.com>; Tb-pl...@mozilla.org <tb-pl...@mozilla.org>; Add-on Developers <add...@thunderbird.topicbox.com>; Jörg Knobloch <jo...@jorgk.com>; Paul Morris <pa...@thunderbird.net>
Sent: Sunday, 2/2/2020, 23:28 23:28 GMT +0000 [Week 6]
Oh! That's good, then. More time for us to prepare. Thanks for clearing that up (I'm not being snide, I'm actually grateful).
Eyal
On 02/02/2020 23:49, Mark Banner wrote:
On 02/02/2020 20:11, Eyal Rozenberg wrote:
with the legacy turn-off now happening for
release users in 78.
Didn't Magnus Melin say 74?
I purposely said release users. Paul's comment was about 74 beta which won't go to users.
The next ESR branch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mozilla.org%2FRelease_Management%2FCalendar&data=02%7C01%7Ceyalroz%40alumni.technion.ac.il%7C142c03bd1f1f46df103f08d7a829bc0c%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637162769521859433&sdata=sL2F89a%2BANgi%2Fml0f76pwdJ5wB%2ByABoxBqvw%2BxxC9io%3D&reserved=0> from which Thunderbird will be based is 78 and won't ship until late June at the earliest.
Mark
------------------------------------------
Thunderbird: Add-on Developers Permalink: https://thunderbird.topicbox.com/groups/addons/Tfb0528f151673de7-Mb34fc9bd3b43d978d0e53b77
Delivery options: https://thunderbird.topicbox.com/groups/addons/subscription
Eyal Rozenberg
On 02/02/2020 10:34, Mark Banner wrote:
> If I remember correctly from an earlier discussion, the percentage of
> users that use add-ons is probably quite small.
> Whilst we don't
> necessarily want to abandon them, I think that should be taken into
> consideration
length. Shall I repeat some of them?
Eyal
Eyal Rozenberg
On 02/02/2020 10:22, Mark Banner wrote:
> iirc
I believe you remember incorrectly.
> The main push to
> WebExtensions came in 68,
Only now are Christopher and others working on making it easier for
people to transition to web extensions, by converting a very simple
extension in a transparent and structured fashion; and IIANM that effort
has not yet been concluded.
> with the legacy turn-off now happening for
> release users in 78.
> transition to me.
way down...
Eyal
Eyal Rozenberg
that up (I'm not being snide, I'm actually grateful).
Eyal
On 02/02/2020 23:49, Mark Banner wrote:
>
>>> with the legacy turn-off now happening for
>>> release users in 78.
>>
>> Didn't Magnus Melin say 74?
>
> I purposely said release users. Paul's comment was about 74 beta which
> won't go to users.
>
> The next ESR branch
> June at the earliest.
>
> Mark
>
Wayne Mery
release cadence is now shorter (4 weeks) so the numbers go more quickly,
but the amount of time between "ESR" releases remains unchanged.
On 2/2/20 6:28 PM, Eyal Rozenberg wrote:
> Oh! That's good, then. More time for us to prepare. Thanks for
> clearing that up (I'm not being snide, I'm actually grateful).
Wayne Mery
posting. (I'm trying Mac and sometimes with the scroll bar not visible
I don't notice that I'm not at the bottom of a message)
Axel Grude
Jon
plugins used by human rights defenders (namely enigmail) will no longer
work and in parallel how the integration of OpenPGP into Thunderbird
directly is going (I am excited about this expanded, built in capacity!).
Public clarity on this, as well as (ideally) not releasing breaking
upgrades to stable channels until OpenPGP is functional, would be much
appreciated for the ragtag group of people hoping to update the current
guides on using PGP/GPG in email.
As an avid and long-standing Thunderbird user, however, thanks to all
for their work, and I'm excited to see the current flurry of activity!
Jon
On 2/3/20 3:25 AM, Axel Grude wrote:
> So I am still a little confused. When did 68 "officially" go live?
> Following the shorter release cycle, when ESR 2020/21 will land for the
> public, is it going to be v 80 or 78.3? It cannot be 78.1 unless we
> significantly shorten the ESR period!
>
> Having an earliest deadline would be crucial for managing our user's
> expectations. I am also still not sure whether at that stage shipping
> Add-ons as experiment in order to avoid gaps such as incomplete /
> inaccessible code points (e.g. drag and drop / forbidden UI parts /
> missing APIs) will still be an option?
>
> I absolutely would prefer to avoid my users losing crucial
> functionality- and being forced to stay back in 68 for a
> considerable amount of time.
>
> Some highlights: QuickFolders would be very much less useful without d&d
> and full CSS access to style the toolbar. I assume we already have some
> replacement tech in place for keyboard shortcuts / global key listeners?
> For SmartTemplate full access to the editor html is still needed. I
> cannot remember whether Mozilla wants to deprecate the old html editor
> or whether it's going to become part of c-c?
>
> Axel
>
> Axel
>
> On Mon 3 Feb 2020, 03:57 Wayne Mery, <vsee...@lehigh.edu
>
> It is incorrect that there is more time to 78. That is because the
> release cadence is now shorter (4 weeks) so the numbers go more
> quickly,
> but the amount of time between "ESR" releases remains unchanged.
>
>
> On 2/2/20 6:28 PM, Eyal Rozenberg wrote:
> > Oh! That's good, then. More time for us to prepare. Thanks for
> > clearing that up (I'm not being snide, I'm actually grateful).
> _______________________________________________
> tb-planning mailing list
> https://mail.mozilla.org/listinfo/tb-planning
>
> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>
Jon Camfield
PGP: D776 2A79 A1AE F000 7F53 A127 B46A 01C3 270C 17F1
Mobile/Skype/Signal/XMPP on request
Magnus Melin
>
> What's the technical reason for de-supporting restartless
> traditional/legacy add-ons? Simplification of the code base?
> Simplifications at ATN?
>
> I can understand that you want to de-support legacy XUL add-ons that
> use TB's own overlay loader since Lightning will no longer require it.
>
> Basically you will terminate almost all add-ons with TB 74, and that
> doesn't sound like a gradual transition.
Add-ons will have to be updated for Thunderbird 78, no matter what.
Bootstapped add-ons should generally be easy enough to convert to
MailExtension Experiments - but of course still need to account for
everything else that is going away and changing. What I'm saying is,
what type of add-on it is seems unlikely to be a barrier for adoption.
This was announced in October which gives add-on authors almost a year
to prepare until Thunderbird 78 is live around 2020-06-30. I think
that's pretty gradual.
-Magnus
Magnus Melin
> Also, sorry to intrude but I'm following along to better understand when
> plugins used by human rights defenders (namely enigmail) will no longer
> work and in parallel how the integration of OpenPGP into Thunderbird
> directly is going (I am excited about this expanded, built in capacity!).
Enigmail will not work in Thunderbird 78, which for end users will be
released around 2020-06-30.
Thunderbird built-in OpenPGP support is going ahead, but not yet at a
stage where it's usable.
> Public clarity on this, as well as (ideally) not releasing breaking
> upgrades to stable channels until OpenPGP is functional, would be much
> appreciated for the ragtag group of people hoping to update the current
> guides on using PGP/GPG in email.
Yes, we certainly intend to have it ready for Thunderbird 78.
-Magnus
Magnus Melin
> I cannot remember whether Mozilla wants to deprecate the old html
> editor or whether it's going to become part of c-c?
Mozilla is actually putting some effort into the editor improvements
now, which will be of benefit to Thunderbird too. We will have to make
some adjustments though.
-Magnus
Axel Grude
Subject:Re: Current timeline for de-supporting traditional add-ons
From:Magnus Melin <mkmelin...@iki.fi>
To:Tb-pl...@mozilla.org <tb-pl...@mozilla.org>
Sent: Tuesday, 2/4/2020, 13:09 13:09 GMT +0000 [Week 6]
On 2020-02-03 22:48, Jon wrote:
Also, sorry to intrude but I'm following along to better understand when
plugins used by human rights defenders (namely enigmail) will no longer
work and in parallel how the integration of OpenPGP into Thunderbird
directly is going (I am excited about this expanded, built in capacity!).
Enigmail will not work in Thunderbird 78, which for end users will be released around 2020-06-30.
June! That's very early! - that doesn't feel like the ESR
support period 2019/2020 is even close to a year? I
know 68 was shipped "late" but feel it gave our (Add-on) users a
much needed "breathing period".
I am very doubtful there will be anywhere close to enough APIs available then for what we are doing, so we will have to ask our users to "stay back" - and no doubt loose some Customers. I was hoping for an automatic push in October at the earliest; can you elaborate on the practical side how the automatic transition into the new ESR period is planned?
As the minimum effort, provided we rewrite all XUL code and remove overlays, can we still use XPCOM in experiments with 78? Completely removing XPCOM is my major pain point at this stage. The official communications haven't been very clear on this subject, they seem to push APIs that don't exist.
PS: "minimum effort" is still a major time investment for big
Add-ons. Most Add-on authors also have day jobs, I am going mine
part-time, but it is close to 30hours/week just doing development
/ marketing / support. So please do not assume we are just lazy.
regards,
Axel
Paul Morris
On 2/4/20 9:52 AM, Axel Grude wrote:
can we still use XPCOM in experiments with 78?
Hi Axel,
WebExtensions experiments allow
"your extension to interact with Thunderbird, much like earlier
types of extension did"[0], and I'm pretty sure that that includes
using XPCOM.
The usual points about using experiments apply, as documented
here:
https://developer.thunderbird.net/add-ons/tb78
-Paul
[0]
https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html
-- Paul Morris Thunderbird.net
Magnus Melin
June! That's very early! - that doesn't feel like the ESR support period 2019/2020 is even close to a year? I know 68 was shipped "late" but feel it gave our (Add-on) users a much needed "breathing period".
The ESR time span is the same it always was.
I am very doubtful there will be anywhere close to enough APIs available then for what we are doing, so we will have to ask our users to "stay back" - and no doubt loose some Customers. I was hoping for an automatic push in October at the earliest; can you elaborate on the practical side how the automatic transition into the new ESR period is planned?
The last point release of the 68 series will roll out around 2020-08-25 and 68 End of Life is 2020-09-22, so that's the latest we'd be holding off on upgrading 68 users to 78.
As the minimum effort, provided we rewrite all XUL code and remove overlays, can we still use XPCOM in experiments with 78?
Like Paul wrote, yes, experiments can basically do anything.
-Magnus
Mihovil Stanić
That means, TB 68 will be 10 months old when TB 78 ships, but probably around 13 months old when 78.3 hits automatic update channel.
Will
>
>
> On 02/02/2020 10:22, Mark Banner wrote:
>> iirc
>
> I believe you remember incorrectly.
It also misses the fact that a lot of users who did use them were
automatically forced to abandon them by the fast update to 60 and rapid
withdrawal of old packages so they could not revert. Nearly caught us out
Philipp Kewisch kindly wrote some code to update one of the plugins we
need but it only partly fixed the issues and needs more API points.
https://github.com/DownloadTicketService/dl/pull/78
We have not had the time to follow that up further as yet - we have no
skills with this sort of code ourselves, and no one else has either.
We have another plugin to work with our CRM that syncs emails and
contacts that has not been touched yet. It may get some attention at
some point but we have no idea when.
Without them we will be on 52.x until we can be bothered to find another
mail client or find someone who will update these plugins to work
properly for us. It really is that simple, much as we want to upgrade.
Ironic that if we can't get the plugins updated it matters less which
email client we use because they will all be very similar at that point.
Plugins were what really separated TB from the rest, and that edge has
gone.
We've offered to pay for them to be fixed. No takers. It has been a
depressing time.
There are not enough users to get enough developers interested in
writing plugins even for cash, and those that do are being forced away
because of the continual changes eg CompactHeader addon.
This is a tad ironic:
Add-on Support Engineer
"To ease the process for add-on authors to convert their code over to
the new way of doing things, as well as making sure needed APIs are
available, the Thunderbird team is looking for someone to help add-on
authors make the jump for the next version (Thunderbird 78). "
We'd say you are about 3 years too late. That should have been done at
the start, not now. And in any event, what is the point if you think
that very few users actually use plugins? It is illogical.
If anyone knows anyone who would like to fix our two add ons for cash
then let us know.
Rgds,
Frustrated.
Eyal Rozenberg
> Add-on Support Engineer
> "To ease the process for add-on authors to convert their code over to
> the new way of doing things, as well as making sure needed APIs are
> available, the Thunderbird team is looking for someone to help add-on
> authors make the jump for the next version (Thunderbird 78). "
>
> We'd say you are about 3 years too late. That should have been done at
> the start, not now. And in any event, what is the point if you think
> that very few users actually use plugins? It is illogical.
You need to remember that Thunderbird is a project in crisis, gradually
abandoned by Mozilla (and IMHO, denied a large amount of money which
Mozilla should have gotten from Google over the years). A small number
of volunteers have had to work very hard to keep Thunderbird going _at
all_, extensions or no extensions. And it is only now that funds are
even available for that kind of a position. Also, 3 years ago, there was
nothing in need of adaptation: The breakage started later than that.
So while I share your frustration, I think you're channeling it
ineffectively.
Also - Mark Banner is himself an add-on author; I made a
somewhat-annoyed reply to him (which in hindsight I should probably have
toned down), not the Thunderbird council.
Eyal
Ryan Sipes
I'll defend the Council a bit too. It took time to scale up to this where we are at now, and donations were not near what they are now. So hiring 3 years ago was about getting a skeleton crew in to keep the project from falling apart completely.
Now that we have the resources the Add-ons Support Engineer is
feasible. But its not the first resource we have thrown on
add-ons. Geoff has done considerable work in this area. But this
is an acknowledgement that this is a big job and we need more
folks on it.
Tanstaafl
> Add-ons will have to be updated for Thunderbird 78, no matter what.
> Bootstapped add-ons should generally be easy enough to convert to
> MailExtension Experiments
way that that process could be leveraged to automatically start
collecting all of the 'Experimental APIs' being used by those Addons, to
provide a list of potential new permanent APIs that should/could be added?
Magnus Melin
> On Tue Feb 04 2020 08:09:47 GMT-0500 (Eastern Standard Time), Magnus
> Melin <mkmelin...@iki.fi> wrote:
>> Add-ons will have to be updated for Thunderbird 78, no matter what.
>> Bootstapped add-ons should generally be easy enough to convert to
>> MailExtension Experiments
> Out of curiosity... since all Addons must be signed, is there not some
> way that that process could be leveraged to automatically start
> collecting all of the 'Experimental APIs' being used by those Addons, to
> provide a list of potential new permanent APIs that should/could be added?
Thunderbird doesn't currently require add-ons to be signed.
I don't understand, how would signing make it easier to collect
experimental apis? Ideally yes, an experimental api, when well designed,
would be absorbed as a new official API.
-Magnus
Tanstaafl
> On 2020-02-06 21:04, Tanstaafl wrote:
>> Out of curiosity... since all Addons must be signed, is there not
>> some way that that process could be leveraged to automatically
>> start collecting all of the 'Experimental APIs' being used by those
>> Addons, to provide a list of potential new permanent APIs that
>> should/could be added?
> Thunderbird doesn't currently require add-ons to be signed.
> I don't understand, how would signing make it easier to collect
> experimental apis
somehow, and that we could leverage that process to 'grab' the
experimental APIs...
> Ideally yes, an experimental api, when well designed, would be
> absorbed as a new official API.
experimental Addon that is submitted to the Addons site, grab the
experimental API, and add it to a list of possible new permanent APIs?
Walter L Schwartz
On Thu Feb 06 2020 14:28:20 GMT-0500 (Eastern Standard Time), Magnus Melin <mkmelin...@iki.fi> wrote:On 2020-02-06 21:04, Tanstaafl wrote:Out of curiosity... since all Addons must be signed, is there not some way that that process could be leveraged to automatically start collecting all of the 'Experimental APIs' being used by those Addons, to provide a list of potential new permanent APIs that should/could be added?Thunderbird doesn't currently require add-ons to be signed.Odd... I thought they did. Apologies...I don't understand, how would signing make it easier to collect experimental apisMy thought was, signing is a process whereby each Addon must be reviewed somehow, and that we could leverage that process to 'grab' the experimental APIs...Ideally yes, an experimental api, when well designed, would be absorbed as a new official API.So... shouldn't there be a formal process for reviewing each experimental Addon that is submitted to the Addons site, grab the experimental API, and add it to a list of possible new permanent APIs?
Isn't this that process?
<https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html>
Magnus Melin
>> My thought was, signing is a process whereby each Addon must be reviewed
>> somehow, and that we could leverage that process to 'grab' the
>> experimental APIs...
Signing and reviewing are two different things. One doesn't imply the other.
>>
>>> Ideally yes, an experimental api, when well designed, would be
>>> absorbed as a new official API.
>> So... shouldn't there be a formal process for reviewing each
>> experimental Addon that is submitted to the Addons site, grab the
>> experimental API, and add it to a list of possible new permanent APIs?
>
> Isn't this that process?
>
> <https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html
>
Correct, scroll down to the bottom of that page.
-Magnus
Tanstaafl
> On 2020-02-07 03:50, Walter L Schwartz wrote:
>> Isn't this that process?
>>
>> <https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html
> Correct, scroll down to the bottom of that page.
the bug. There are a lot of reasons that they may not do this (not aware
of the process, meant to but forgot, etc).
I firmly believe that the best way is for there to be a specific process
that is part of the Addon being uploaded to the Thunderbird Addons site,
where the Author is required to check a box that their Addon contains
'Experiments' and provide some documentation about it, which would
automatically set a flag for a Thunderbird Core Dev to look at it,
document the API as a potential for adding to Core, and activate an
internal review process.
Otherwise, we are just wasting an opportunity to much more quickly get
ahead of the game and provide feature rich APIs available to ALL Addon
developers.
This could go a long way to alleviating/nullifying all of the negative
publicity and complaints about the loss of full featured/functionality
based Addons.
At least that is mho...