[Blog post] Mozilla's Manifest v3 FAQ

[zombie (Tomislav Jovanovic)]

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.

Does such a roadmap exist? If not, would Mozilla please be willing to create and publish one? […] my hope is that Mozilla has a clear, strong internal vision

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.

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.

Please file this, and any other specific use cases you may find, and make them block bug 1578286 so that we can track them.

[Heurekus]

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.

[gorhill (Raymond Hill)]

Please file this, and any other specific use cases you may find, and make them block bug 1578286 so that we can track them

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.

[zombie (Tomislav Jovanovic)]

Thanks, you should have that power (editbugs) from now on.

[zephyr]

Thank you for taking the time to address the roadmap.

[BelFox]

Firefox is my beloved browser for three main reasons:

1. Privacy
2. Customizability
3. Independency

Therefore, I hope changes to the extensions API

• do not take away any of the existing possibilities (no regression just because of compliance with Google’s Manifest or marginal security/performance improvements)
• add new possibilities instead (eagerly waiting for a Toolbar API )
• are seen as an opportunity to make Firefox stand out compared to other browsers (common APIs + FF specific APIs)

In Firefox, the user has control. Stay true to these values and I will keep promoting FF to whomever is listening

[dannycolin]

• add new possibilities instead (eagerly waiting for a Toolbar API )

For the Toolbar API, you can follow bug 1215064.

[Lusito]

Please help me gather some thoughts to bring up at MozFest:

Collecting your thoughts about Manivest V3 and the Recommended Extensions program

As the developer of a recommended extension (forget me not), I have been invited by Mozilla to join a full day workshop at MozFest. The workshop has been described as: The focus of our day together will be exploring ways to optimize the Recommended Extensions program, improve the overall quality of its content, and gather your thoughts on Firefox’s approach to Google’s Manifest v3 changes. I have my own opinion on these topics, but I thought it would be a good idea to collect some more thoug…

[g.roblin (GR)]

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 !

[thatrandomguy (John)]

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.

[zephyr]

@zombie Any updates to the roadmap around webRequest?

[zombie (Tomislav Jovanovic)]

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.

[dvir (Dvir Cooper)]

@zombie
bumping up this thread - just checking if you have timeline for V3 release and V2 end of life?

[zombie (Tomislav Jovanovic)]

Still no changes.

We will definitely make noise when we have an update, you don’t need to worry.

[AndRo_Marian (andro.marian.v94@gmail.com)]

Maybe this time will fix the dark and light theme to be to background and not to text.

browser_action - Mozilla | MDN

[aaFn]

Posting here as I just got a mail about Manifest V3 inviting me to do so:

as I see it, and similar to @gorhill above, removing access to a DOM would break my extension “Bookmark search plus 2”.

I already signalled that in https://bugzilla.mozilla.org/show_bug.cgi?id=1578286#c8 2 months ago (note: I cannot figure out how to mark it as blocking, I probably do not have sufficient rights to do so … or I am blind ), so this post is probably duplicate to some extent.
However, since I was invited by the mail to signal such a case of incompatibility, I prefer to say it also here, in case somebody has news on this topic, or if there is a workaround coming.

Of course, if at the occasion of V3, Firefox would solve https://bugzilla.mozilla.org/show_bug.cgi?id=1411120, which is at the origin of my workaround needing access to a DOM, that would nicely solve the problem as then I would probably be able to remove that corresponding portion of code

Thanks, aaFn.

[birtles]

Hi!

Thank you for the heads up about Manifest v3.

I am concerned that it may not be possible to use Web Workers from a background Service Worker.

My add-on provides dictionary look ups and updates the dictionary on initial install and weekly thereafter. It is important that the updates occur in a web worker since otherwise any other interaction with the background page will be blocked while that is happening. (It’s dealing with just short of a million IndexedDB records and no matter how finely you slice it, it ends up all but blocking the thread it’s running on.)

So far I cannot find any way to generate a Web worker from a Service Worker. If it is not possible, Manifest v3 might represent a significant regression in my extension’s performance and responsiveness.

[zakius]

I hope you are aware that there are multiple extensions that are functioning perfectly well despite not being updated at all for years that will stop working once v3 becames the only supported format. And that many actively maintained extensions are simply too massive to migrate with the power of a single developer. And on top of that I’m concerned about capabilities, available APIs, WE still miss a lot after the 2017 massacre and it seems we’ll lose another chunk of power for the sake of being chromium compatible

[Lusito]

One of those extensions is mine: forget-me-not.

My use-case: I store information about open tabs in memory, so I can know when it is possible to actually clean up data without interfering with running pages.

Doing this with background services would require me to rewrite the extension almost entirely from scratch and lose a lot of features in the process.

While I do get that you want to reduce memory consumption, in some cases this will result in worse performance. For my use-case, I would have to store and restore all that I know about the open tabs whenever something of interest happens (requests, tabs opening, etc.).

If this change goes through, I’ll probably have to retire the extension.

[juraj.masiar]

Maybe the planned new in-memory storage will help?

The following features will be added to MV3 soon:

• In-memory storage: a new StorageArea on the Storage API that can be used to store values in memory across service worker restarts.

Most of my problems will be solved by it (I think, or hope ).