
A grim outlook on the future of browser add-ons - todsacerdoti
https://palant.info/2020/08/31/a-grim-outlook-on-the-future-of-browser-add-ons/
======
aswan
(disclosure: I am a former member of the Mozilla addons engineering team. I
haven't been a Mozilla employee for more than a year and don't have any
internal information about recent developments)

Regarding Android: As many folks probably already know, the new Firefox for
Android is a complete rewrite of the front-end to use an embedable version of
gecko (GeckoView). This entails re-implementing all the extension API support
that existed in the old monolithic browser. The timeline for switching from
the Fennec (the original Firefox for Android) to Fenix (the GeckoView based
version) was driven by a bunch of conflicting things. In an ideal world it
wouldn't have happened until the extension support was broader, but we reached
a point where Fennec can't be maintained any longer yet full extension support
in Fenix isn't ready. I don't agree with the way Mozilla has handled this, but
to be fair to them -- if they provide a way to easily enable extensions that
they haven't tested they will be flooded with reports about extensions that
don't work. Sorting through all this would be a huge distraction to a team
that's already busy trying to complete the extension implementation. It seems
popular here to be skeptical about Mozilla's goals and ascribe hidden
motivations to them, but if you follow the work that's happening on GeckoView
extensions (go to bugzilla.mozilla.org search for product GeckoView, component
Extensions), you can see that progress is happening slowly but steadily.

As for desktop and additional extension APIs: I think that this is another
place Mozilla has dropped the ball on communication. WebExtensions support a
concept of "experimental APIs" with which developers can easily prototype new
extension APIs. The intention here was always that this would be an avenue for
developers outside Mozilla to experiment with new ideas that could eventually
become regular apis available to all extensions. To be clear, the bar here is
high: among other issues, many things that developers would like to be able to
do from extensions are prone to abuse by malicious extensions. Figuring out a
way to create an API that allows for customization while also helping users
understand how extensions are changing their browser and make an informed
choice about whether to allow it is a difficult problem! The developer
community seemed to take Mozilla's intention to expand extensions'
capabilities as a promise to have Mozilla employees do all that work, rather
than an invitation to work together with the community on the process of
designing new APIs that can be used in a safe way.

~~~
the8472
> if they provide a way to easily enable extensions that they haven't tested
> they will be flooded with reports about extensions that don't work.

Well, it _used_ to be the case that extension had to explicitly declare which
applications they support (e.g. thunderbird, seamonkey, firefox). That's not
the case anymore with the webext manifest format, but at least temporarily
mozilla could have introduced some sort of opt-in by extension developers to
avoid this scenario without gatekeeping. The assumption would then be that the
developers tested that the available api subset on android is sufficient for
their extension.

> The developer community seemed to take Mozilla's intention to expand
> extensions' capabilities as a promise to have Mozilla employees do all that
> work

I was interested in that, but when I looked into it it turned out that it was
limited to developer edition and required two separate extensions to be
installed it's a lot of work that only a handful of users could ever test and
after going 2 migrations (XUL -> jetpack -> webext) it felt like yet another
temporary thing with uncertain future. It seems to have changed a bit since
then, so maybe it's worth looking into it again.

~~~
aswan
> at least temporarily mozilla could have introduced some sort of opt-in by
> extension developers to avoid this scenario without gatekeeping

Yep, I agree completely. In the mean time, there is
[https://github.com/mozilla-
mobile/fenix/issues/14034](https://github.com/mozilla-
mobile/fenix/issues/14034)

As for experiments, the days of two separate extensions are long gone :) The
point about multiple migrations (you didn't even mention e10s!) is a fair
one...

------
loughnane
I'm ok with Mozilla making it _harder_ to install add-ons. Requiring going
deep into the settings could be a useful enough friction that a lot of privacy
and experience issues are solved for the average user.

But a strict prohibition on apps really seems antithetical to what they stand
for.

