As a developer of a browser supporting WebExtensionsAPI, the move to v3 is going to add so much complexity.
For developers, maintaining browser extensions across browsers with different support for WebExtensionsAPI is going to become a major PITA.
Even right now one can not submit a new Chrome extension unless it is v3 so that means that extensions codebases have to be branched out for Firefox and Chrome which was not the case before.
The hardest will be on the browser side of things. Supporting both v2 and v3 sides of an already extremely complex API (which is what we plan to do) will be causing a lot of issues.
The situation is not good. The lack of standard and unity does not help the web.
Actually I feel the pendulum has stopped a few months ago and is slowly starting to go back. Some major things in my world:
- I now only have one website I need to use that only works in Chrome.
- Devs seems to start to care
- LibreWolf is starting to give Mozilla a run for its money
- I'm optimistic that we will see some break through, sooner or later, where Chrome will be punished as hard as IE was: fines, regulations and a browser choice dialog for starters (but please folks, it can happen a lot faster if it it isn't just "that one weird loon", so do contact your local authorities and do complain about how Chrome has destroyed a thriving ecosystem. And if you work in Google, do ask tough questions.)
> Firefox no longer makes part of browser matrixes, and is mostly ignored by QA teams.
which is how a browser dies - when sites and apps stop checking whether they are complying with web standards using more than a single reference browser.
Hopefully, chrome becomes like the IE of old, and a new "chrome" comes along to rescue the web.
As far as I understand the move to V3 from Firefox means will be able to ship the same App for chrome and Firefox.
Firefox just supports some additional APIs which are essential for good AD blockers Google killed.
But if you don't need this additional API (or don't have the time to support them) you could just ignore them.
That is once the move to v3 fully succeeded.
> The situation is not good.
Yes the way Google turns Chrome into a de-facto standard sidestepping or force feeding normal standardization procedures is not good.
(Slightly over simplified:) Like the most common problem with running Firefox is that it's more strict with CORS related stuff, like the standard originally intended, but ups, Chrome had already implemented less strict checks and didn't want to brake any websites so that became part of the standard to (i.e. the more strict part became optional).
On the one hand it's good to remember Manifest v2 is from a long long time ago, before Web Extensions API was a glimmering in anyone's eye. It was simply the chrome extension api back then.
It was powerful & capable. But it wasnt a standard, other than that it was by far the highest potential most capable most interesting user-agency extension on the planet by a good measure.
What's so fucking twisted is that we're undergoing "standardization" in v3 at the exact same moment Google is radically rewriting & reshaping the api to be far far far less capable.
It's hard to see a single win from any of the changes. After achieving world dominating success, the very last moment before standardization these chums have repealed a huge swarth of changes, all untested & unproven. It's amateur hour, just a sas ahit show right before standardization. devlarativeNetRequesr has some ostensibly good & virtuous advatanges, but it was obviously shit & deeply insufficient in the most woefully obvious of ways. Eliminating dynamic code was tacked on as a pro-security gimmick that didnt even remotely take technical interest & possibity into concerns: oh whoops we accidentally blew up userscript extensions, sorry, but you're all safe now.
This whole thing deeply deeply walks the line between vicious & evil farce & accidnetal fuckwittery. I still tend to give these folks the benefit of a doubt, that they simply lacked vision & respect & understanding & werent actively sabotaging & neutering the web like it certainly looks like.
That all said, v3 is actually the first proposed standard, seemingly sabotaged & crippled that it may be. So when you say this, I think, no, alas, everyone is for the first time trying to join up, just, alas, it's for misbegotten quite-possibly-sabotaged greatly de-fanged trash:
> As a developer of a browser supporting WebExtensionsAPI, the move to v3 is going to add so much complexity.
> But it wasnt a standard, other than that it was by far the highest potential most capable most interesting user-agency extension on the planet by a good measure.
While the Chrome extension API was certainly the most wide-reaching at the time, it wasn't the most capable. I used to have a Firefox extension that made Win32 API calls. Mozilla ended up deciding it wasn't sustainable, I guess?
The extension API for Firefox was simply the entire internal api of the browser. Making it work cross process (everything was single process) was a huge pain and things were going to break depending on how you used the APIs. And the security considerations of accessing every api was a big issue.
On the other hand, Firebug could not have been created without it…
I very very very rarely try to declare someone's feature to be an anti-feature, but as a Linux user: the feature you proclaim is- distinctly & clearly- a huge antifeature I want kept far away from the web & it's extensions. What is a feature to you is a huge will not run anywhere else to me.
lack of standard is crippling but offshoots of factions defying the pecking order is a good thing. Giving options besides big G is a good thing. Unfortunately it means most projects starting for browsers will start with chromium based as the market share is mainly there.
I’m in the same boat and feel the same. It’s just not a great state of things for extension development, and yeah the separate Firefox and Chrome code in my codebase truly irks me.
No, for certain changes in Manifest V3 there is no way to polyfill the V2 API because the functionality is essentially removed/impossible to do now.
Also, other aspects (like switching from background pages to service workers) require a change in programming model (moving from simple variables to message passing/persistent storage) as your service worker can be killed off at any time.
> No, for certain changes in Manifest V3 there is no way to polyfill the V2 API because the functionality is essentially removed/impossible to do now.
But isn't the whole announcement about Firefox also going to support v3 (e.g. you only need to write for v3) except that it still allows some of the removed functionality _additionally_ to the v3 APIs Chrome has?
> Also, other aspects [..]
Yes, that will be a major change. But as far as I understand one you have to go through anyway if you want to support Chrome.
> But isn't the whole announcement about Firefox also going to support v3 (e.g. you only need to write for v3) except that it still allows some of the removed functionality _additionally_ to the v3 APIs Chrome has?
Right - maybe I misunderstood the previous commenter's question, but I thought they were asking if it would be possible to make a translation layer that would allow developers to seamlessly support Manifest V3 without changing their Manifest V2 code.
What you are saying is correct though - Manifest V3 code will be universally supported, with a few browsers (Firefox, and Brave I believe) also supporting some of the V2 APIs on top of that. But if you use those APIs it won't work in Chrome.
For developers, maintaining browser extensions across browsers with different support for WebExtensionsAPI is going to become a major PITA.
Even right now one can not submit a new Chrome extension unless it is v3 so that means that extensions codebases have to be branched out for Firefox and Chrome which was not the case before.
The hardest will be on the browser side of things. Supporting both v2 and v3 sides of an already extremely complex API (which is what we plan to do) will be causing a lot of issues.
The situation is not good. The lack of standard and unity does not help the web.