MV3 Service Workers Don't Support Websocket

[Cuyler Stuwe]

I'm writing an extension which is meant to extend the functionality of a family of apps into the web browser.

In our current lineup, our mobile app, desktop app, and MV2 browser extension can push data up to our server. That data is then immediately propagated to the other active apps immediately via a GraphQL subscription enabled via WebSockets through Apollo.

It's important for the usability of the product that this update is synchronized immediately.

MV3 doesn't support the persisted connection that our users need in order to use our product.

What's the solution?

[hrg...@gmail.com]

Simeon himself proposed this: https://bugs.chromium.org/p/chromium/issues/detail?id=1128240

It might be the solution to all these limitations in MV3.

[Cuyler Stuwe]

Yeah.

But it doesn't seem that there's any movement on it; It seems that he and the rest of the Google team are worried that they might actually make it useful.

It seems almost like those responsible for this decision are trying to avoid admitting that removing background pages was a bad idea and was poorly thought-out. 

If the outcome of this proposal would be that people develop extensions like they would in MV2, that's a sign that maybe there was nothing wrong with the way things were developed in MV2. And I'm not sure that really helps them stubbornly toe the line for MV3's service worker model.

[Cuyler Stuwe]

It really feels transparent that the #1 reason we don't have an API like this is just that someone would have to "eat dirt" by admitting they didn't think something through.

[Cuyler Stuwe]

... and it feels that despite being told that we should continually prove cases where MV3's model is insufficient, there's only *crickets* when real examples like this are offered.

[Mark S]

This is immediately relevant for me as well...I've been debugging WebSockets in a v3 extension over the last few days. I'll post back with a solution once I'm there. 

[Cuyler Stuwe]

Honestly, Mark, it has been immediately relevant for a lot of extension devs for a long time.

This isn't the first time the issue has been brought up here, but we have been asked to offer examples so that the unimaginative can finally understand why it's an issue.

If we offer a wide enough variety of examples frequently enough, then perhaps we'll get some softening on the parts of MV3 that are infeasible for production applications.

There are some janky workarounds, sure... but each of these workarounds is essentially just making a "fake" background.js page:

- Extending the service worker by making it await an indefinite promise and demanding that it do work every 5 minutes to stay awake. Service worker is now effectively background.js.
- Opening a new browser tab and/or window and instructing the user not to close it, then using this window/tab to do all of the extension's background processing; Just a background.js with worse user experience.
- Injecting into all domains and trying to make some sort of overengineered bug-prone nonperformant shared state-management between content.js files, delegating one of the content scripts to handle processes that would have been handled in background.js.

- etc.

As w0xx0m has pointed out in the past, this "service worker" issue (and the problems it intends to solve) is a relic of the past, originally proposed as a solution to problems that existed almost 8 years ago. The device landscape has changed significantly since then, and it doesn't seem that Google has acknowledged this. For example, in 2021, a budget $205 Chromebook comes with 4GB of RAM (that it doesn't even have to share with a memory-hungry OS like Windows), and mid to mid-low tier Windows laptops around the $400 mark tend to ship with 8GB. Google is fundamentally seeking to resolve problems that arguably no longer exist. Mind you, a single instance of their own New Tab Page in an empty profile takes 35MB RAM on my mac, and Gmail takes about 200MB RAM per-tab. Within these RAM-plentiful circumstances we live under today, Google has been "generous" enough to offer us 2.86% of the RAM usage of a New Tab Page for the brain of our extensions to persist in memory. If the user so much as opens a second Gmail tab, they put memory pressure on their device that's 200x the maximum we can persist.

I really don't know what a good solution is to any of this if Google doesn't budge -- It feels like they're making a platform that will force all of us to bypass its intended outcomes.

[Alexei Miagkov]

You may be interested in adding your thoughts to https://github.com/w3c/webextensions/issues/51. I think it would be helpful for more extension developers to chime in with practical examples of how MV3/Service Worker-based extensions hurt them and their extensions' users.

>unimaginative

I know MV3 and particularly the way it's been presented is very frustrating, but this kind of language won't help get your points across.

--
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/CA%2BYuxde%3DZOHSXtae-uz6e2J5NaAxUpTZsXXaXrLG9WoGses8wg%40mail.gmail.com.

[Cuyler Stuwe]

To add here:

Another janky solution would to have it so that your extension loads a tab of its own during browser startup. The user would be required to conceptualize your app as running only so long as that tab is open. All ongoing browser processes needed by this extension would be directed by this tab which we instruct the user not to close. This would mean that we would need a warning prompt if the user tries to close it, and clicking the extension icon would either open a new instance, or focus the existing one.

Ultimately, as with the rest of these, this workaround is essentially just recreating background.js with a significantly-degraded UX.

But out of all of the workarounds I've thought up, this one seems to be the one that's the "least bad" if Google refuses to budge.