A number of extension developers have reached out to ask how Mozilla plans to respond to the changes proposed in Google’s update to their extensions API, commonly known as Manifest v3.
We have answered some of the frequently asked questions on the Add-ons Blog, and we welcome feedback on this thread.
Background service workers […] whether there is a benefit in continuing to maintain background pages.
Removing access to a DOM would currently break uBlock Origin (“uBO”). uBO uses a DOM element to validate plain cosmetic filters – which are essentially CSS selectors. Having access to the DOM to validate plain cosmetic filters allow uBO to detect and discard or further process invalid cosmetic filters.
Using invalid CSS selectors in an injected stylesheet could entirely break cosmetic filtering where this occurs. There has been instances where CSS selectors valid in one browser were not valid in another browser, or valid in a version of a browser were not valid in another version of the same browser (i.e. CSS4), so detecting invalid CSS selectors has been key to ensure uBO works as intended on any browser while using the same filter lists in all browsers, and without having to burden filter list maintainers about incompatibilities between browsers.
If there is a way to solve this requirement without a DOM that would be great.
I may stumble on other DOM dependencies, the one above is the obvious one I know about.
Hi
I am fairly new with making content for FX, so apologies for ignorance. Is this change going to impact theme creation?
Hey @Seburo, that’s a good question. This may affect themes – the version number in the manifest file would need to be updated if we move to a “version 3” – and there are some changes that would impact dynamic themes. It’s still too early to say anything more specific, though.
Content blocking: We have no immediate plans to remove
blocking webRequestand are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.
Please be advised that the statement may be received as a bit milquetoast even if that is not the intent; I believe that a published roadmap for blocking webRequest would do much to inspire developer confidence. In my case, I have a plugin that does NSFW image moderation fully client side and so it doesn’t follow the usual ad blocking use case that has garnered public attention - and perhaps the protection, as it were, that that attention might help ad blocking use cases attract. However, I believe Mozilla wishes to take the high road on this, and to me the thing that separates statements of commitment from merely gladhanding or appeasement is a clear roadmap. In my mind, a roadmap is the perfect foil to something embroiled in controversy like this, as it embodies the whole, well-formed dream that Mozilla has around the feature set - Chrome or not! - and speaks to the future we wish to see and build.
Does such a roadmap exist? If not, would Mozilla please be willing to create and publish one? From the existence of the API extensions already in place e.g. filterResponseData my hope is that Mozilla has a clear, strong internal vision of this and as a part of your community I’m wondering if we can get a peek at it.
Thanks for making the browser that makes my plugin possible!
Remotely hosted code : Firefox already does not allow remote code as a policy. Manifest v3 includes a proposal for additional technical enforcement measures, which we are currently evaluating and intend to also enforce.
Please do not do this. At best, users should have the ability to vet and approve remote scripts individually or at an extension-level, not to have them blocked outright. There are legitimate cases for needing remote scripts, and introducing this change will break Greasemonkey, Tampermonkey, and Violentmonkey, all of which rely on loading code from outside of the extension.
Users shouldn’t have to be forced to create and publish entire extensions to load custom scripts. Users most definitely shouldn’t be charged money for this either.
I would also argue that custom scripts are much safer than any extension as the user sees the entirety of the code being executed.
Hi @mitozen, first of all, welcome to the Mozilla Discourse community.
I think there is a misunderstanding here, as the extensions you name actually just got it’s own API, so they can inject user scripts into websites properly.
So I doubt Mozilla will take away the special possibility they have just introduced.
So “Remotely hosted code” likely still just refers to code inside of the add-on that has elevated privileges (those of add-ons). E.g. when an add-on includes a script from the add-on author’s website. This was and likely will stay disallowed.
User scripts only have access to the current website…
Rugkx is correct, this only refers to remote extension code, which is already disallowed on AMO. We recently added an API specifically to support safe usage of user scripts, we love and fully support them.
Our roadmap is still in development since it also depends on other market players (primarily addon authors). Parts that we are most sure of, and to the extent that we’re confident are presented in this FAQ, with more details coming later.
Please file this, and any other specific use cases you may find, and make them block bug 1578286 so that we can track them.
I use blocking webrequests to abort loading a page when a TLS certificate has changed and the author wants to authorize this first (TLS certificate pinning, see add on https://addons.mozilla.org/de/firefox/addon/certificate-pinner/)). Removing the blocking webrequests API would render my add-on unusable.
New issue filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1580254
I do not have the power to modify the bug to mark it as blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1578286.
Thanks, you should have that power (editbugs) from now on.
Thank you for taking the time to address the roadmap.
Firefox is my beloved browser for three main reasons:
Therefore, I hope changes to the extensions API
)In Firefox, the user has control. Stay true to these values and I will keep promoting FF to whomever is listening 
Please help me gather some thoughts to bring up at MozFest:
I can’t rewrite my extensions if there’s big changes, i don’t have the time to do that, and why removing a lot of capabilities of extensions, it’s what it make great tools !
As long as Ad-Block and NoScript extensions still work, I don’t see how this can be bad. That is, so long as the above remains true. There is simply no good reason for the above to be false at any time—none. Google can take the “high road” by taking more means to prevent ad-block but Mozilla doesn’t need to. If anything, Mozilla has taken every step to do the opposite from what I recall. This should be no different.
No changes, and unlikely to have anything to add for another ~half a year, or until after Chrome blocks webRequest, and we see how addon authors react to that.
We will definitely make noise when we have an update, you don’t need to worry.