Anyone else really hating Manifest V3?

With Chrome forcing Manifest V3 onto developers of add-ons on their platform, I’ve started the annoying task of migrating my add-on. But, to be honest, it seems like the MV3 spec wasn’t really thought out very well, especially when it comes to replacing persistent background scripts with service workers. Some features just plain don’t work.

The most broken thing I’ve noticed is with port-based messaging between content scripts and the service worker. Apparent, the connection to the port automatically closes after 5 minutes, which kind of defeats the purpose of registering a port in the first place.

Something else I’m having an issue with is that service workers can’t play audio because they don’t have a window object. Sadly, this makes something as simple as playing an alarm clock noise in the background practically impossible. That seems like a big oversight to me.

Having to constantly read values from the Storage API instead of depending on cached values from the background script is a HUGE hit to performance.

This post is kind of off-topic, but I just felt the need to rant a little on a non-Chrome forum, where the answer is always “what you’re trying to do is stupid, just do it this way”.

6 Likes

What are their solutions to the problems you mentioned?

I have been using port-based messaging to retrieve most of my settings from the background script, instead of forcing each content script to query the Storage API for those values. I used to have the content scripts load them on their own, however, I found I got better performance if I saved the data from the Storage API on a variable in the background script and just refreshed the variable when a change is made to the storage.

The performance improvement doing it that way is quite noticeable, especially since my add-on is injecting CSS based on those settings at the soonest possible time. Now, some elements on the page are flashing when the page loads because there’s a gap between when the page is fully loaded and when the appropriate settings have been retrieved from the Storage API. Previously, there was no flash because the settings were always available before the page DOM loaded.

The people on the Chrome forums said that my approach using port-based messaging was wrong and that I should just use the Storage API, completely ignoring the obvious performance impacts of doing that.

I did, however, get given a hacky workaround regarding ports. Apparently, if I set alarms to close and re-register the ports every 4 minutes, that will not only keep the ports alive, but it will also keep the service worker persistent. I’m probably not going to do that though, since there’s still the possibility that the service worker will terminate if there are no content scripts running, in turn dropping the cached settings.

As for the audio, I was told that I would that there “probably isn’t a good approach” to playing audio. I tried opening a new tab in the background to play the sound, but the audio won’t actually start until the tab is selected. A workaround that seems to work for me (as far as I’ve found) is opening a tiny popup window and then immediately returning focus to the window the person was using. When the sound is done, the window closes. Again, not the ideal situation, but I guess it works.

Just to let everyone know, it looks like the WebExtensions Community group continues to meet and discuss issues like these and there is involvement with many parties including Mozilla and Google. If you look at the meeting minutes, they have discussed how they are suprised Google is moving forward with all of this without resolving some of the technical challenges. (Meeting Minutes)

2 Likes

Google does what Google wants to do…