Use cases for long-lived connection in service worker?

[ohpyupi]

We had an existing extension in MV2, and we used long-lived connection for communication between content scripts and the extension background script. And it worked really well in the boundary of MV2.

But in MV3, since the service worker has lifetime cycle, it can go inactive, and the open ports will be disconnected. But because content scripts are not aware of the status of service worker, if the content script sends a message to inactive service worker, then the content script will get an error. This makes the long-lived connection very unreliable in the MV3 regime, and seems like replacing it with one-off messaging is a way to go?

I cannot really see use cases of long-lived connection in service worker at all. Is there any future plan to deprecate the long-lived connection in service worker or any behavior changes?

[tophf]

There was never any meaningful discussion over all these years - the Chromium developers either completely ignored our concerns or gave a template answer that this new behavior improves resource usage, which is actually false for nontrivial extensions that hook into high-frequency events.

There's a clunky workaround shown here which is to "Reconnect each port before 5 minutes elapse".

[ohpyupi]

Yeah absolutely agree. And the implementation of the workaround can cause more resource wastes, which directly conflicts with the v3 initiative rationales.

I noticed that Firefox's MV3 will include event-driven background script(https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/), and the event-driven background script will not terminate if there is long-lived connection.

If the direction of Chromium extensions is discouraging the use of long-lived connection, I think deprecating long-lived connection in Chromium MV3 would be more helpful for developers.

[tophf]

Ports can be useful even within the currently broken design of MV3 in case the extension sends a lot of messages in that 5 minute interval because reopening of the port once per the interval consumes much less resources than reopening it each time a message is sent (this is what happens under the hood when one-time messaging is used).

[ohpyupi]

I agree that long-lived connection is useful. Another point is the service worker has maximum 5 minutes of lifetime. But not sure always service worker live up to maximum. I saw sometimes, the worker goes inactive less than a minute. So the interval period can be lesser to make sure the availability.

I mean developers now need to deal with those situations in Chromium MV3 development environment. I think the design should be more helpful to reduce such work for developers.

[tophf]

The port is guaranteed to live for 5 minutes, but there are some bugs mentioned in that thread that need special handling. BTW the fact that this trick works at all is an evidence of a poor design of MV3 and AFAICT it can't be disabled without fundamentally breaking the background scripts.

A good solution would be to let the users decide if they want to allow an extension to benefit from having a long-running background script instead of wastefully restarting it every minute.

BTW, only service worker closes the ports, whereas in other extension contexts the ports live forever.

[ohpyupi]

Yeah. This is a trick and something that doesn't seem to be aligned with the MV3 design at all. This is very confusing. I understand devs want to keep long-lived connection, and I'm one of them.

I think it should've been one of the following cases to reduce the confusion:

• (1) Deprecate the long-lived connection
  • It just does not work without a trick.
  • And gives clear guidance on how to replace long-lived connection
• (2) Long-lived connection keeps service workers alive and persistent.
  • Event-driven scripts do not suspends when active long-lived connection is there.
• (3) Long-lived connection handles the disconnected ports automatically
  • Keep service workers ephemeral, but the long-lived connection handle restoring disconnected ports automatically so that devs do not need to implement their own hacky restoration mechanism.

[Jack-Works]

but the long-lived connection handle restoring disconnected ports automatically so that devs do not need to implement their own hacky restoration mechanism.

I agree. We should at least have this, otherwise, it will be a nightmare to migrate. We wrote a complex message API based on Message Port (we need a lot of messaging). And suddenly we need to switch back to a one-time message to keep it working normally. It's a big hurt to performance.