Dropping legacy support: Moving forward

Magnus Melin mkmelin+mozilla at iki.fi
Tue Oct 15 12:56:03 UTC 2019

On 15-10-2019 00:09, Tanstaafl wrote:
> On 10/7/2019, 6:03:29 PM, Magnus Melin <mkmelin+mozilla at iki.fi> wrote:
>> On 06-10-2019 12:33, John Bieling wrote:
>>> One question is of general nature and thus I want to ask it here:
>>> *Why will WebExt Experiments be disabled in a few years?*

This is a misquote actually. What I wrote was "but over time (years) 
Thunderbird will gravitate towards not having the experiments available 
to the general public, the same way it works for Firefox".

There is really no timeline, and we'd have to see how it all unfolds. 
The core part of the message was not to cut off experiments, just to 
make it clear moving towards API usage is preferable.

>> When everything deemed essential is available through WX APIs, there
>> is little reason not to use that instead.
> Please don't take this the wrong way, but... who, exactly, is capable of
> making such a decision? Some one or group of TB core devs? Who may (or
> may not) have thought of some of the APIs that may be essential to others?

An API can't have everything. But it's possible to look e.g. at if most 
important add-ons have been able to stop using experiments. If the 
remaining add-ons have small user base, that is a good indication.

> I think the point is that the idea that 'everything deemed essential is
> available through WX APIs' will never be the case.
> I understand that a line may need to be drawn, but my concern is that
> the ones doing the line drawing should err on the side of allowing as
> much flexibility as possible.
>>  From the Thunderbird core point of view, we want our users to have
>> long time stability, and that also includes essential add-ons.
> Which is an excellent argument that whatever someone deems as 'Essential
> Add-Ons' are pure WebExts, so that they don't have some of the potential
> problems that WebExps may have.
> The point is, you make it clear to Add-On devs - if you choose the
> WebExp route, you will potentially have a lot more work keeping your
> AddOn working.
> As long as there are sane tests, and a process for marking broken AddOns
> as broken (and blocking their installation from stable releases), who is
> harmed? Certainly not the TB core devs.

We spend *a lot* of time discussing add-on brokenness and how to get 
add-on authors to update their add-ons. You can't really automate 
finding broken add-ons (except to perhaps find find some obvious things).

Users are certainly harmed if an add-on malfunctions, or they get 
changed behavior because they were used to a certain behavior due to an 
add-on which now isn't working.

>> Forcing users to rely on an experiment (which can easily have a bumpy
>> ride, and stop being maintained) is not ideal.
> It may not be ideal, but that is a problem for the WebExp AddOn dev, and
> more importantly, is simply not a valid reason not to allow the
> continued use of WebExps.
>> 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.
> And it will be the responsibility of the AddOn Devs to deal with such
> cases - as it always has been. I certainly don't think anyone is
> suggesting otherwise.
>> 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.
> With WebExps, as I see it, we get the best of both worlds...
> Stability with pure WebExts - so any Addon dev that desires stability
> over additional functionality/maintenance pain works within the pure
> WebExt environment.

You may be underestimating how bumpy of a ride it may be to keep up with 
the changes over a few years.

> Added functionality/capabilities to advanced AddOn devs, with the
> understanding that it comes at a cost of *possibly* more work to
> maintain it.
> But most importantly...
> Web Experiments provide a fertile testing ground for defining new APIs
> that may provide more robust and safer ways to modify things, providing
> both  more flexibility and more safety.
> Why should this ability not be maintained indefinitely?

That's what Firefox (currently) does, but it's not exposed to normal end 
users. Just dev-edition and nightly.

> I can even envision some kind of program where core Devs engage with
> AddOn devs (on request) to assist in helping to devise the needed API,
> or even better, modify an existing one if it made more sense.
> There is only one argument I can see that would be valid, but I haven't
> seen anyone make it yet...
> If it ever gets to the point that it is extremely difficult/expensive in
> terms of resources (money) to maintain the environment for WebExps, then
> and only then does it make sense to look at shutting it down once and
> for all.

If you want to talk resources, I'd say add-ons support is much 
overspending what they "bring in". There is no financial justifications 
to spend more then necessary on them. Just try the numbers, it will fail 
bigtime. Remember maybe around 10% of users use add-ons *at all*. Maybe 
that means 1% is really what should be allocated for add-ons, if 
supporting them would be purely due to financial calculations. Where 
does that put experiments in some years? 0.05%?


More information about the tb-planning mailing list