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.
2 Likes
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.
2 Likes
Thanks, you should have that power (editbugs) from now on.
3 Likes
Thank you for taking the time to address the roadmap.
1 Like
Firefox is my beloved browser for three main reasons:
- Privacy
- Customizability
- 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 
3 Likes
Please help me gather some thoughts to bring up at MozFest:
3 Likes
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.
1 Like
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.
@zombie
bumping up this thread - just checking if you have timeline for V3 release and V2 end of life?
1 Like
Still no changes.
We will definitely make noise when we have an update, you don’t need to worry.
Maybe this time will fix the dark and light theme to be to background and not to text.
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.
1 Like
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.
2 Likes
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
2 Likes
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.
2 Likes
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 
).
2 Likes
My extension is a productivity timer, and I am concerned about losing accuracy on Manifest V3.
I currently run a persistent background script to check if future timestamps have been reached. If so, a notification is sent to the user.
Will probably switch to the Alarms API when migrating, but it has some caveats:
- The time at which it fires is arbitrary, per the docs.
- If an alarm has to be reprogrammed to < 1 minute from the current time, it would not be possible per the minimum time restriction.
- Existing alarms are delayed when the device is locked or asleep. See this bug. With the new architecture, the only way I can think of checking if the alarm is delayed is by having an additional periodic alarm every minute, but even that alarm would be delayed because of the locked state.
- Triggering a service worker with onStateChanged could help mend the previous point, but Firefox does not support the ‘locked’ state on idle.idleState.
All in all, users will probably experience up to a ~1 minute delay from the actual time their notification was supposed to be sent.
More guarantees on alarm execution time would be nice. If not, maybe more control on the time a service worker stays active would help. Tasks that need to happen within the minute could be delegated to a timeout in the service worker.
1 Like