Two years ago, Chrome announced their plans for Manifest v3, which would make a series of changes to their extensions platform. Mozilla will also introduce Manifest v3 to maintain cross-browser compatibility and promote cross-browser extension development, though we intend to diverge from Chrome’s implementation in some areas.
You can read more about our plans for Manifest v3 on the Add-ons Blog.
Supporting background service workers for compatibility is good, but removing support for background pages / scripts is a VERY VERY bad decision.
The inability to access to the DOM and read / write to the clipboard from the background, and the inability to establish a persistent port connection with the Native Messaging Host have led to a number of complaints from Chrome extension developers.
There’s no need for Mozilla to revisit the obvious path of failure.
Refs
I’m pretty sure background pages won’t be staying. It’s a huge part of the addon architecture and keeping it would be too complex to maintain.
I see better chances by requesting those missing features to be implemented in service workers.
Also in Firefox you may be able to use hidden tabs to do some DOM related work.
Anyway, I feel your pain. I’m sweating just by thinking about migrating all addons to V3…
I understand that Mozilla wants to be more compatible with Google Chrome.
If you’re a Chrome extension developer, it’s great for them to see how easy it is to port their extension to Firefox.
However, it is not always true for Firefox extension developers.
It was just four years ago when Mozilla fully migrated to WebExtensions, and extension developers had to pay a lot of effort.
Note that you lost many great extension developers at that time.
I don’t see a good reason to force them to do it again just for compatibility reasons,
What happened 4 years ago with Firefox 57 was different - the old architecture was not sustainable (compatibility / security nightmare) and migration to WebExtension API was a necessary step.
And look where it got us - you have now the same API in Firefox, Chrome and even Safari and Thunderbird - this is amazing for me as a developer because I can release same extension on 4 distinct products with minimum changes 
What we see now with V3 is a “small” evolution step - update - that is suppose to improve things. And many extensions won’t be affected at all.
But I totally agree with you that the persistent background page makes things much easier for developers.
Actually, I’ve been thinking now about my extensions and I have to say that this is gonna make a lot of problems for me 
. My in-memory storage with encryption keys won’t work, my canvas probably too, sub-minute timers (since Alarms have minute granularity), and all those cached data… oh man, I hope this will take a few years for them to finish .
On the other hand I understand that event-based background script is better because it can be killed and will free up memory - since in Chrome each background page is probably in its own process taking who knows how much MB RAM just by running idle javascript.
@juraj.masiar I ended up having to more or less rewrite my addon back in November/December to use hidden tabs instead of just a background page because a small change in Firefox interacted badly with a Tensorflow.js implementation issue regarding GPU usage when used in the background context. For the curious, you can compare the source in 1.2.1 vs. 2.0.0 - see the addition of processor.html/processor.js. Here were my findings:
It forced a client/server style architecture. It’s doable but quite annoying to basically add RPC to everything if a major feature depends on something you can’t do in the background page. This gave me a more modular architecture ultimately but there is a decent bit of friction, and on top of that quite a bit more room for resource-related bugs around RPC.
I now have to explain to new users that I’m not trying to do anything shady by asking for the hidden tabs permission. Firefox community engagement folks, please understand that if we need to use hidden tabs more often we will either make the permission less valuable because many extensions will have it or on the other hand a few extensions will be branded as sketchy for reasons that probably aren’t actually sketchy.
One concern I have is how the lifetime of the background service worker will work relative to the hidden tabs approach. One of the key reasons to have the hidden tabs is precisely to guarantee persistence, which seems to perhaps run counter to the service worker philosophy. Right now I have to load a Tensorflow.js model that takes a full 10 seconds or so to fully initialize - it’s not something I can have just loaded in and out of memory transparently. So I would be curious is anyone is able to comment on how truly persistent objects can be kept around when background service workers gets turned on. @asamuzaK I’d be curious if you have any thoughts on that as the “hidden tab to background service worker persistent connection” seems to have a similar architectural shape as the Native Messaging Host communication referenced. If there are going to be problems with that, I wonder if some type of special permission could get added so you could guarantee persistence for the background service worker?
Finally, I do think it would be good for the Firefox community to consider that we probably want to avoid having conversations with new developers like this: “Oh, I can’t do X in the background service worker. Wait, I have to what? Add hidden tab, hidden tab permission, tunnel out via RPC - just so I can make the same call?” To that end I think having similar levels of permissions/API surface area for the background service worker as for the background pages now will be one key to success in the transition here like @juraj.masiar was pointing out.
It looks like there is a deadline now:
January 17, 2022
Chrome Web Store stops accepting new Manifest V2 extensions
January 2023
Chrome Web Store stops accepting updates to existing Manifest V2 extensions
And I’m not sure I’m reading this right but the promised in-memory storage has quota 1MB? 
Anyway, I’m still waiting for Manifest V3 support in Firefox, Safari and Thunderbird - I hope they will all make it before January 2023.