Dropping legacy support: Moving forward
mkmelin+mozilla at iki.fi
Mon Oct 7 22:03:29 UTC 2019
On 06-10-2019 12:33, John Bieling wrote:
> so learning WebExt is inevitable now. I have to start from scratch. My
> current knowledge about WebExt: Zero. That is going to be a hard time.
> I will have a lot of questions, which probably only core developers
> can answer. But I think tb-planning is not the right place to ask
> them, but https://thunderbird.topicbox.com, correct?
> As we really need support of core devs to help us, will you follow
> topics there? Time is running fast and answers are needed fast. Will
> you be there?
https://thunderbird.topicbox.com/groups/addons/ would indeed be the best
place to ask.
> One question is of general nature and thus I want to ask it here: *Why
> will WebExt Experiments be disabled in a few years?*
When everything deemed essential is available through WX APIs, there is
little reason not to use that instead.
From the Thunderbird core point of view, we want our users to have long
time stability, and that also includes essential add-ons. Forcing users
to rely on an experiment (which can easily have a bumpy ride, and stop
being maintained) is not ideal. Many times with Web Experiments you'll
still be using and relying on Mozilla internal technologies, many of
which can and will change or disappear over the years.
> We are in this situation, because Firefox/Mozilla decided, that WebExt
> is the new thing. If Firefox would not have done that, we would be
> still be able to create powerful add-ons, which can do almost
> everything. There has never been a security issue with Thunderbird
> extensions. The reason Firefox closed WebExt Experiments, are security
> issues, I think.
There is a security issue with current style add-ons: They can do
anything per design - but that's not a desired design related to security.
> I can understand, that we need to follow the WebExt path, but
> disabling WebExt Experiments is your own choice, right? If WebExt
> Experiments do allow us to do all the things we need, why are we not
> allowed to use them (later)?
> Sure, if there are WebExt Experiments, that are of general use, they
> should be moved as MailExtension API to core. But there will be
> experiments, that will be useful only to a single add-on. Why should
> that be moved into core? And there is still the chance, that it gets
> rejected. Also, it makes add-on development much harder, as you have
> to send patches to core.
If you're referring to the category of "bug-fix" add-ons, there would
naturally not be an API for those. If it's a bug of general interest, we
should just fix that in core.
> I think this question must be answered now, as I do not want to go
> through this in 5 years, when my addons again stop working, because
> WebExt Experiments will be disabled.
To put this in perspective: converting your bootstrapped add-on to an
experiment should not be terribly hard or much work. The work you'd put
into maintaining that add-on over 5 years is by my guess quite negligible.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning