|
|
|
|
|
|
by aswan
2119 days ago
|
|
|
(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. |
|
|
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.