It’s been about a year since our last update regarding Manifest v3. We have started an implementation of Manifest v3 and collaborated with other browser vendors in the WebExtension Community Group (WECG) to shape the future of extensions.
Today, we’re kicking off our Developer Preview program to gather feedback on our implementation of MV3. You can read more about our choices and plans at Manifest v3 in Firefox: Recap & Next Steps on our Add-ons Blog.
Great news! 
Does this mean upcoming Firefox ESR 102 will have MV3 support available as well?
MV3 support will not be released as general availability in time for ESR 102. The ESR in 2023 will be the first with MV3 support.
Losing persistent background pages will be a large blow to many extensions. This change seems intended so extensions can be restarted in Android. What about extensions that aren’t intended for Android? Will there be ways to avoid or delay termination of Service Workers or Event Pages on desktop? Even if an Event Page is designed to be resilient against inevitable termination, there are many cases where it would be more performative if it could delay termination. Here it is noted ( https://github.com/w3c/webextensions/issues/134 ) that you’re unlikely to be applying arbitrary time limits for Event Pages, at least on desktop. Can you give us more details about this?
Google has said they will not terminate Service Workers if they are connected to a native app (once a bug for that is fixed). Will this also be the same for Event Pages or Service Workers in Firefox?
I tried to port two simple MV3 extensions using this migration guide.
The content scripts didn’t work.
Did Firefox forget to add content script support? 
The only “trick” I could do to get them to be recognized was:
Too bad with the ESR 
, I try to stay compatible with last ESR since some people use it. This means I’ll have to wait one more year .
But I’ve tried to convert one of my extensions to Firefox MV3 and I did find some issues:
the web_accessible_resources doesn’t support "<all_urls>", I don’t know why, but *://*/* worked fine.
I’m still getting warning about not supported persistent key:
Reading manifest: Warning processing background: Error processing background: Property "persistent" is unsupported in Manifest Version 3
resource (image) specified in web_accessible_resources won’t load in normal addon page anymore, that’s a bug
I don’t know why but I was not able to inject content script to the page, no errors logged
and even though this is not MV3 specific I have to mention it - the background script console gets STUCK after second reload, so you have close it and reload it ALL THE TIME!!!
Please, please fix this, this is a show stopper for me. I had to migrate my development to ESR because of this bug and soon new ESR will be released with this bug 
. Thanks!
I think we chatted about this over matrix, but the issue is about host permissions, in MV3, they’re not granted automatically on install, but instead user needs to grant them at some point.
Depending on what’s appropriate for your extension, you could ask the user using promise.request() , or they can grant it by going to about:addons, selecting your addon, and flipping the toggle in the permissions tab.
We’re also working on an easier UI to do this, tied to your extension browser action, but that’s not final yet. Thanks for pointing out that this is not clear from the migration guide, I’ll work to get that updated with this info as well.
Thanks Juraj, some answers below:
The syntax for web_accessible_resources is changed in mv3 https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources#manifest_v3_syntax
If the new syntax still doesn’t work, please file a bug with a minimal extension to reproduce.
Please see my comment above about host permissions in mv3.
I’ve pinged Julian on that bug, but let’s keep the discussion here about specific to mv3 issues, thanks!
I wrote my thoughts on the deprecation of the Page Action API in MV3.
Basically, I think it is a bad idea, since it helps prevent people from having toolbars packed with extension icons, and it is a real differentiator from Chrome. Thanks for considering my feedback!
Is there a timeline for ‘sunsetting’ MV2 support?
We touch on that in our most recent update posted yesterday: