Reliably calling setTimeout in service worker

[Moe Bazzi]

Hey everyone,

So service workers do have a setTimeout API, but it can be unreliable since the SW can be cut off and not run any remaining asynchronous code.

But if my setTimeout is in an event listener (e.g chrome.tabs.onActivated) and I only need it to timeout in a couple hundred milliseconds, can I be sure that it will be triggered? 

I cant use the Alarm API since it could take up to a minute to be triggered (even if you specified hundreds of milliseconds or seconds). The task I want to run is time sensitive on the scale of hundreds of milliseconds.

Thanks.

[wOxxOm]

No, there's no guarantee due to an incorrect implementation of the internal timer logic for `chrome` API events in service worker, which is yet another evidence that MV3 service worker is a huge step backwards from the event pages in MV2. This is reported in https://crbug.com/1305369 and https://crbug.com/1371876, but there's still no meaningful reaction from Chromium team, so there's no guarantee this will fixed any time soon if at all.

That said, the statistic probability of encountering the bug is `duration/30sec`, if I'm not mistaken, i.e. for 300ms it's only 1%, so the users might tolerate it thinking they simply mis-clicked. Yeah, I know, very funny. Anyway, they'll click again, the background script will be started anew, and it will live for 30 seconds this time. Undoubtedly bad for performance, bad for the perceived reliability of the extensions in general, and consequently bad for the browser.

The only workaround is to force the background script to live longer, see https://stackoverflow.com/a/66618269.

[Robbi]

I'm afraid that workaround will become a standard implemented by most extensions developers in the near future.

When "everyone" will implement it (and exploit it without restraint) then all the (few) good intentions of mv3 will go to hell.
Finally, it must be said that workaround upon workaround the code becomes more and more "bizarre".

[Moe Bazzi]

So let me get this straight. By definition, a service worker wakes up for at least 30 seconds when a chrome event is triggered, and if another event is triggered within those 30 seconds, it will stay alive for another 30 seconds, but can only do this for 5 minutes max, right?

However, there is a bug that will cause the service worker to die before the 30 seconds period is up after an event was triggered?

--
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/ee13a277-ef2a-4121-86d0-52052bdd2d83n%40chromium.org.

[wOxxOm]

Conceptually yes, it violates the idea expressed in the specification - SW lifetime is tied to pending events. In other words as long as the code doesn't consume 100% CPU for an extended period of time there's a guarantee that SW lives as long as there are pending events. This is actually implemented in browsers.

Back to our case: since anything that can wake the worker must be registered as an event, a `chrome` API internal event must have been registered internally as an SW event, but judging by the fact that they don't prolong the lifetime they aren't registered as lifetime events. It was either a mistake or an intentional ill-advised decision. On the other hand, we can't say it violates the specification because there's no specification for extension service workers, so they're free to be as broken as they want.

> but can only do this for 5 minutes max, right?

The specification doesn't limit the duration of SW lifetime, only of the individual events. This is why it's possible to keep the SW alive "forever" via runtime ports.

[Robbi]

The ironic thing is that they've always fooled us with slogans like: "Use workers to not block the main thread and to give the user a better\richer browsing experience"
Now we are constrained  to open windows, popups, tabs or communication ports to accomplish medium complexity jobs, when with MV2 it would not have been necessary.
A big step forward indeed!!!
I wonder if it wouldn't have been better to switch to the event pages (deprecating persistent: true) in a first step, thus giving developers time to get used to the idea of saving their extensions states\variables in the asynchronous storages, and then do the final quantum leap with MV3 and service worker in a year or two (when most of the problems would have been solved in the meantime)?

[wOxxOm]

That would be a sensible approach, which is what Mozilla does in its implementation of ManifestV3.

Unfortunately ManifestV3 team in Chrome is governed by idealists.

[hrg...@gmail.com]

The idea of replacing a background page (persistent or not) with a service worker is just sad. Somebody on that team messed up big time and they are now trying to fix the mess via "offscreen documents".

[wOxxOm]

That would be more than one developer in Chromium team. The idea to switch extensions to a service worker was in development since at least 2014, and judging by various comments on crbug there seems to be a shared dogmatic belief in the idea that a persistent background script "consumes CPU cycles even when idle" to such a degree that it becomes a non-imaginary problem in the big picture, although we haven't seen any proof of that. From what I've seen myself, it's a super rare edge case: extrapolating to the world scale it'd be like 0.001% of the entire uptime of all extensions combined. A better solution would be to inform the user about the misbehaving extension, maybe even automatically disable it, but those ideas were rejected in favor of crippling the platform for everyone, which is certainly easier to implement.

[hrg...@gmail.com]

One thing is to eliminate persistence, but quite another is to eliminate the background page entirely.

It's understandable that they eliminate persistence if the long term goal is to allow the extension platform to work under Android which doesn't allow persistent processes.

But it really makes no sense to replace a non-persistent background page with a service worker.

If they thought that they would reduce their maintenance costs by replacing a non-standard technology (the event page) with a standard technology (the service worker), they were clearly mistaken as we can all see the Extensions Team struggling to make the service worker to even work properly; let alone to make it a suitable replacement for a background page.