@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