Manifest v3 is going to be a slaughter. Extension developers have known the slaughter was coming, but Chrome users are going to be taken by surprise. Many free Chrome extensions aren't going to get updated at all for v3, because it's too much work. Many aren't going to work right anymore because of the new restrictions. And ad blocking aside, v3 seems like a nightmare in general, and still quite buggy. The service workers vs. background script issue discussed by AdGuard will affect many or most extensions.
I've been postponing the migration of my extensions to v3 for as long as possible. One extension should be fine, but the other one... I'm afraid of what that's going to be like.
> but Chrome users are going to be taken by surprise. Many free Chrome extensions aren't going to get updated at all for v3, because it's too much work
On one of the occasions I flipped from mostly Firefox to mostly Chrome/Chromium¹ was due to significant changes to add-ons – and an add-on that was one of my significant points for friction stopping me move over more was one that didn't get updated immediately².
But I think many people will blame the add-ons, and just stick around & complain instead of moving away from the source of the problem. The many dozens of us who will move, not matter how loudly we do so, simply won't be important enough in the grand scheme of things for Google to care.
----
[1] this happens every few years² as one or the other irritates me in various ways
[2] I'm currently long overdue a move towards Firefox, maybe V3 will be the final push this time around
[3] in fact, for some time IIRC, by the time a new version appeared I no longer needed it
> The service workers vs. background script issue discussed by AdGuard will affect many or most extensions.
This is so true. It is often overlooked, but the root problem of Manifest V3 is not declarativeNetRequest, but this service worker move.
Firefox and Safari implemented an alternative to them so there's a chance.
Google proposed a different solution (called "Offscreen documents") which is also not too bad, but I doubt they'll implement it by the January deadline.
The main issue is that their lifetime is limited and they're getting constantly killed. This happens all the time even when the service worker is being actively used.
This is by design. The downside to background pages is they consumed an entire page's worth of runtime resources (and depending on how they're set up, they may do that per foreground tab).
It's a headache early-era iOS developers are familiar with, but this move is basically Chrome team saying "We've watched the community try to implement responsible resource handling, and they suck at it, so we're taking some of their choices away so that the browser can manage resources for the user." Because battery matters.
This question was discussed so many times in W3C group.
Mostly this boils down to one thing: there needs to be an alternative to service workers and there are tons of legitimate use cases for long-living background pages or workers. I think by this point everyone agrees on that, the question is when this alternative will be made available to developers. It’s only 3 months until the deadline after all.
NGL, I did find MV3 harder to implement against. Not because of the declarative model alone, but because the declarative model's rules are under-documented.
Can you replace an image URL fetched remotely with an image stored in the extension itself (via rewriting the URL from a remote fetch to a file fetch)? Maybe? No, because redirection from remote URLs to file URLs trips the resource fetch security model independent of anything else, except a developer has no reason to believe that security model applies also to extensions?
Testing against the declarative model feels very wild west and since it isn't just JavaScript, I can't just slap the debugger on it and introspect all the data going back and forth.
I've been postponing the migration of my extensions to v3 for as long as possible. One extension should be fine, but the other one... I'm afraid of what that's going to be like.