Are most of the existing add-ons being sacrificed due to adding support for WebExtension?

Philipp Kewisch kewisch at
Wed Nov 22 14:44:25 UTC 2017

** This was originally a reply a bit further down in the thread, which I accidentally posted to the maildev list instead of tb-planning. Let's keep tb-planning for process questions, if you want to talk about the technical merits, please head over to the maildev list **

Hi Günter, all,

As you may know, Jörg is part of the Thunderbird Council. He is also
doing everything possible to ensure that Thunderbird is still in a
usable state, so while I wouldn't say he is directly responsible for
add-ons in Thunderbird, he is doing a good job keeping tabs (no pun

I'm happy to reiterate and expand a few things Jörg has said though.

Firefox has spent the last 2+ years working with a large team on making
WebExtensions a success. I think they have done a great job in
delivering the new ecosystem and making sure add-on authors port their
add-ons (though I am biased, being part of that team).

When this came up, there were broad concerns that Thunderbird would do
the same, and that we'd be taking away some of the customizability by
following the WebExtensions path. Our stance back then, which continues
to be true today, is that we would do anything reasonably possible to
maintain support for legacy add-ons.

In part this is because we didn't have the community contributions nor
staff support to work out a concept for WebExtensions, but also because
we didn't know how extensible the Firefox implementation of
WebExtensions would be and if we could adapt it to our needs.

The way it was implemented in the Mozilla Platform, it is possible for
Thunderbird to follow the WebExtnsions path, and given we might need to
make more drastic internal changes to keep Thunderbird sustainable in
the future it might actually be a good thing. In fact, simple
WebExtensions that only use toolkit APIs can already be installed. Other
prominent APIs like the tabs API will need to be reimplemented, and we'd
have to extend to provide Thunderbird-specific APIs. We will let
tb-planning and add-on authors know if we are going this route and how
they can be a part of it, but I'm pretty sure this will not be relevant
for 59.

Regarding the email you may have seen, Mark kindly told us about changes
that might require authors to use embededed WebExtensions due to the
options changes, but to me this is mainly a note to Thunderbird
developers that we need to find a workaround for this. If we determine
the only viable path forward is to frame everything in an embedded
WebExtension, we might consider automating this change for all
Thunderbird add-ons.

For Thunderbird 59, we will be taking measures to minimize the changes
needed for add-on authors. I don't want to go into technical details of
the specific bugs, but if we can find a way to continue providing the
same features as before, we will do our best to comply. A guide as to
what needs to be changed for Thunderbird 59 is a good idea, I hope we
can get this guide written with help of the community.

I hope this answers many of the questions that have come up, please feel
free to reply if you have further concerns.


On 11/22/17 4:08 AM, Eric Moore wrote:
> "In general, there have been many interface/IDL changes over the
> mozilla57/58/59 period and some changes to JS syntax that most add-ons
> will require some sort of update to their code. That will distinguish
> the "maintained" add-ons from the "unmaintained" add-ons some/most of
> which will stop working.
> ....
> Jörg."
> Who made the decision to essentially kill off legacy add-ons and when
> was it made?
> Who was aware of that decision?
> Why wasn't this treated as a strategic decision that needed
> feedback/discussion like was done with getting a new home?
> A lot of what makes Thunderbird so popular is its large collection of
> user developed add-ons. My impression is that many users have given up
> due to poor doc., too frequent changes to interfaces, and uncertainty
> about the direction of add-ons. Look at Paolo "Kaosmos" for example. A
> cookbook on how to convert a legacy add-on and migrate to a new
> add-ons web site isn't going to change that.
> What is the plan to deal with the bad publicity when web sites like
> hear of this?
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list