Service Woker lifespan and setTimeout

[Sonny Chee]

Hey Guys,

So I am in the process of migrating to MV3 and before I make the final changes, I have a few outstanding questions, I hope someone can help me with.  Any help would be greatly appreciated.

In regards to the following quote from (https://developer.chrome.com/docs/extensions/mv3/service_workers/)

"Once it has been loaded, a service worker keeps running as long as it is performing an action, such as calling a Chrome API or issuing a network request. Additionally, the service worker won't unload until all visible views and all message ports are closed."

So if I communicate with my content scripts via ports established with chrome.runtime.connect and I do not explicitly disconnect the ports, does that mean the Service Worker will remain loaded indefinitely?

Additionally, if that is true, then it seems I should be safe in continuing to use setTimeout and setInterval - as long as I keep my ports open.. yes?

[Cuyler Stuwe]

Can’t do that.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/51f66bc0-4787-438f-a92b-ab22ecd8620dn%40chromium.org.

[wOxxOm]

>  "Once it has been loaded, a service worker keeps running as long as it is performing an action, such as calling a Chrome API or issuing a network request. 

Not exactly. It will unload if the action takes more than 5 minutes, which is the hardcoded limit in Chrome. However, a network request issued via `fetch` will be terminated in 5 minutes anyway per the specification and there's no XMLHttpRequest now so in this case it's a moot point, but not so in case of WebSockets which don't have an inherent timeout so MV3 breaks such extensions. For the sake of technical accuracy, the worker should also unload during an unusually long Chrome API call such as chrome.identity.getProfileUserInfo if the user didn't respond before the timeout, but I didn't test it myself.

>  Additionally, the service worker won't unload until all visible views and all message ports are closed."

No. First, the worker won't even start when an extension page is opened if that page doesn't send any events to the worker. And even if it did, the worker unloads after the default timeout: 30 seconds or up to 5 minutes if extended via waitUntil or onMessage with `return true` or by using a chrome.runtime port. The chrome.runtime ports are forcibly auto-closed after 5 minutes though and here's the funny thing: the extensions team believes it's working as intended (WAI) even though this behavior can be trivially circumvented by reopening a port before 5 minutes elapse, which unequivocally makes this ostensibly intentional restriction not only yet another evidence of MV3's weak design but also of the team's unreasonable attitude that they have been demonstrating each time an MV3 lifetime issue is brought up.

> Effective background scripts stay dormant until an event they are listening for fires, react with specified instructions, then unload.

No. Another false claim from the same article. Real effectiveness depends on what the extension does. Only extensions that behave like on-demand apps benefit from having a non-persistent background script whereas extensions that actually extend the browser and hook into various frequent events become much slower and waste orders of magnitude more CPU/battery/disk resources (due to frequent restarts of the service worker) compared to a persistent background script that 99.999% of time doesn't do anything, just waits for an incoming event. Hopefully, the extensions team will implement a flexible timeout, but given the fact that such a foundational problem wasn't addressed since the very beginning it's probable they will implement it in an arbitrary fashion yet again without actually measuring the impact on performance in real nontrivial extensions with a breakdown by percentiles.

>  I should be safe in continuing to use setTimeout and setInterval - as long as I keep my ports open

No. You'll have to randomly reopen ports to keep the service worker alive or open a visible tab/window that will act as a visible background page, consuming several times more memory/CPU/battery resources than the MV2 background page. More info in this answer. The latter is advised in MV3 migration materials despite its increased use of resources and being a terrible UX approach. After all, it's a viable strategy as demonstrated by the extensions team: never look at the task manager and never measure the real performance, just keep believing everything's improving because the overall idea looks so good. Seriously though, someone wake them up. The MV3-related documentation/communication has been making a lot of false claims, especially in articles about the most controversial an practically unnecessary changes enforced in MV3, so don't take anything there for granted and verify each claim. The technical writers and the actual developers aren't doing it intentionally, of course. The notion that a persistent background page is bad and a service worker or an event page is good has became a kind of religiously worshipped staple inside the team over the years as I see the first mentions dating back 10 years, even though no one has ever verified it and no one in the team doubted it, either because that would be "nonconstructive" or because they sincerely thought that since a service worker helps the web so much then it must help extensions, but they're wrong as the extensions are completely different, they're not sites or web pages, they're already local so they don't benefit from a service worker, on the contrary they often need to integrate into the browser so deep that the huge delays incurred by a restart of the worker are unacceptable.

[Jorge Dardon]

Thanks for your in depth breakdown, W0xx0m. This is truly tragic for developers and users.

I'm still trying to understand how I can get around the limitations of V3 like our friend up top.

1) If an extension uses something like Firebase auth for authentication and the token is stored in something like IndexedDB, does a service worker have to reauthenticate everytime it "dies". (in the case of firebase, call signInWithCustomToken again and again ?) 

2) Is an extension that checks every page once for form fields and autofills them considered one of the types of applications that you mentioned would benefit from having a nonpersistent background script AKA service worker?

I would greatly appreciate your wisdom here.

Thanks.

[wOxxOm]

Firebase is broken in MV3 from what I remember seeing in multiple threads over here so try searching.

>  Is an extension that checks every page once for form fields and autofills them considered one of the types of applications that you mentioned would benefit from having a nonpersistent background script AKA service worker

No. A service worker would restart for every page load separated by more than 30 seconds (default) or 5 minutes (extended via waitUntil). A page load is an example of such a frequent event that makes MV3 so bad due to the lack of a persistent background script. That said, there may be no need for a service worker in your case at all, a content script may be sufficient. Start a new thread and describe the use case in more detail.

[Sonny Chee]

Thanks for the detailed response wOxxOm. That was very helpful.