Is the communication with content script stuck/ not happen at all due to the service worker being inactive?

[Jaliya roshen Jayarathne]

One of the major changes with transition to MV 3 of the chrome extension manifest  is the introduction of the service worker. Therefore, in the absence of interaction between scripts, this become inactive as follows. What are the disadvatanges of this service worker due to this?. I have seen some extensions stuck and popUps are not working as expected beacuse of this inactive state. That means manually we have to active the service worker. Is there any workaround for this?

[T S]

Locally, this shouldn't matter too much - the service worker will wake up if a content script sends a message or starts a connection, or any other event occurs for which it has a listener.

However, if you're hoping to do any persistent background work, the outlook is bleak.  It sounds like the current behaviour is a 5 minute hard timeout, with a caveat for native messaging?  Of course, this behaviour isn't documented anywhere, so I could be very wrong.
I really hope this gets reconsidered.  For all the manifesto's focus on capability, this dramatically shrinks the value that extensions can provide.

[Jói Sigurdsson]

> the service worker will wake up if a content script sends a message or starts a connection,

> or any other event occurs for which it has a listener.

A bit of a caveat, it should wake up, but it will only wake up if your user is not bitten by the (fairly common) bug https://bugs.chromium.org/p/chromium/issues/detail?id=1271154

Let's hope Google fixes that issue well in time for the January MV3 deadline.

Cheers,

Jói

[T S]

Fair point.

Having done a little testing, it certainly SEEMS like a service worker with e.g. an open websocket will remain open indefinitely now - but I'm guessing this behavior definitely isn't guaranteed.

It looks like chromium is converging on offscreen documents to handle some of the previous usecases for background scripts, but as these will still have limited lifetimes, they could still be unwieldy.

[wOxxOm]

Judging by the source code, only nativeMessaging keeps the worker running forever, so maybe you had devtools open for the worker. It freezes the kill timer.

[T S]

Yeah, you're right, I must have had devtools still attached without realising.  That's a shame, I really don't want to have to be dependent on foreground tabs or injected keepalives but it sounds like it's unavoidable.