Confused About Service Worker Lifetimes

[Mike-O]

Can someone point out to me some explanation (a nice link on the web) about service worker lifetimes in MV3 Chrome Extensions? My greatest fear is that I make an MV3 extension with a panel and content script that somehow can't communicate with the service worker with message passing due to the service worker suddenly becoming inactive. What exactly wakes up the service worker? Where should I be putting listeners such as when a tab is created or updated -- I assume the service worker, yes?

I created a sample extension with a panel and a button to send a message to the service worker and get a response. There have been times, of which I cannot accurately reproduce consistently and don't know if it was a coding mistake or what -- where the message to the service worker timed out and it didn't respond because it had gone to sleep. That kind of scared me.

[hrg...@gmail.com]

One thing is how MV3 is supposed to work and another whether it actually works.

The way MV3 is supposed to work is this:

• The service worker can be terminated at any given time.
  
• The service worker will start again whenever a message arrives.
  
• If the service worker adds a message listener during its first task (i.e. before yielding the thread), that message listener will receive the message that woke it up.

Whether this actually works or not... well... not such much. Its rather buggy.

I'm still delaying my MV3 migration as much as possible as MV3 is still not a sound platform to develop with.

If you can't wait, you'll have to deal with buggy and inconsistent behavior for many more months.

Let's hope that at some point during this year we can finally say that MV3 at least works as intended.

[Mike-O]

So, if I need to send a message to the service worker, would it be prudent to first send a wakeup message (of which may error out because the service worker might have gone to sleep, but, will, by that message, wake up again) before sending the message you really need, at least until this inconsistency bug is ironed out?

If this is true, then wow, the Google Chrome Extension team really needs to recognize the following problems and perhaps reconsider their Jan 1, 2023 deadline for MV3:

• Service workers not waking up consistently when being sent a message after long idle times.
• The declarativeNetRequest feedback not working consistently or having super low quota limits such that you can't update the icon badge with an accurate count on how many items being blocked.
• The declarativeNetRequest regex or url filter dynamic rules having too low of a quota to be useful.
• The DevTools doesn't have a chrome.storage editor and it requires a third-party plugin -- luckily it's free and actively maintained by some generous coder, although that editor won't load on a service worker's DevTools, although that service worker can interact with chrome.storage.

[hrg...@gmail.com]

That's a possible workaround, but you don't know how long it will take for the service worker to start up, so you just don't know for how long to delay the message that you really want the SW to receive. A one-second delay might work most of the time, but not always.

Plus, if the user is expecting a quick response, this workaround will make everything seem slow/unresponsive.

Also, this workaround does not apply to messages that you don't control such as "tab created", "tab updated", "tab closed", "toolbar button clicked", etc. There's nothing we can do to "fix" those cases.

[Rutik Wankhade]

Did you find a workaround? is there any way to make service workers active like background scripts?