Use case for persistent background scripts & other concerns

[Chandler Davis]

Good day, everyone!

I have taken on a new role in my company that involves me maintaining our browser extension which is based on MV2. I have a few concerns about the migration to MV3, and I was hoping to get some guidance.

For some background, we sell a bluetooth LE device that integrates with our password management software. Basically, as long as the device is in range, you can have access to your passwords. 

The implication of this is that our desktop app needs to tell our Chrome extension "hey, the device is still in range!" regularly through a WebSocket. In fact, the extension's only way of getting sensitive data is through that WebSocket. I understand that WebSockets are still allowed in MV3, but I am concerned that the ephemeral nature of service workers will make this process impractical if not infeasible. 

Sure, it's not a problem if the user doesn't need their credentials for a while, but what Chrome API could be called to 'wake up' the service worker after it dies? I've seen a good bit of workarounds in this forum talking about doing some arbitrary Chrome API call every 4.9 minutes to keep it alive or keeping a tab open specifically for the extension to run, but in my opinion these are hacky and counterintuitive. 

Even if there was an MV3-compliant way to go about this, the user would no longer be able to see battery % or do basically anything at all in the extension if the service worker is not active.

I'll admit that I may not be getting the full picture here, but it seems that disallowing persistent background scripts in MV3 more or less breaks our entire Chrome platform. From what I have read around here, there are plenty of other people that have similar concerns and I hope that we will be able to find a solution that works for us all.

Also, I would like to politely note that the documentation for MV3 can be a little lacking--it's unclear how Chrome handles the lifecycle of Service Workers (i.e., conditions and timelines for becoming active/inactive). There's also not a lot of great guidance for maintaining state, other than the "in-memory storage" thing that doesn't seem to be a good replacement due to storage limits. All in all, I felt that a few questions that MV3 raised for me were far better answered in threads here than they were in the official docs.

I look forward to hearing y'alls thoughts on this!

[Cuyler Stuwe]

Please copy and paste your comment here, or else it will unfortunately likely be ignored:

https://github.com/w3c/webextensions/issues/72

--
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/fdb404fb-51a2-42b7-b9d7-3e0496f32187n%40chromium.org.

[Chandler Davis]

Done, thanks for the tip!

[Cuyler Stuwe]

For sure.

I’ve been a browser extension specialist for several years now, and am also working on MV2 -> MV3 transitioning for the company I’m currently working for.

I have similar problems with service workers and WebSockets. The only real solution we’ve been able to come up with for the time being is to persist a visible window/tab that we tell the user to ignore. Obviously, this is a ridiculously terrible UX, but it’s less bad than the functionality simply not existing. 🤷‍♂️

Here’s to hoping that Google will listen to a voice of reason.

[Carlos]

I suggest to also mention it here:

https://github.com/w3c/webextensions/issues/44

This proposes to allow the background page to stay persistent even if it's a serviceWorker.

Op dinsdag 12 oktober 2021 om 15:53:34 UTC+2 schreef salem...@gmail.com:

[hrg...@gmail.com]

There's so much stuff that needs to be added to a service worker in order for it to be useful... I can already see that after several years of patching it and extending it, we'll end up back at the beginning... which we should have never left, a persisten background page.

rdevlin said the following at https://crbug.com/1225642#c9

"I'd also generally say that unless there's a good reason a web API should *not* be exposed to a worker, we should lean towards it being exposed."

So now they want to solve the SW problems by changing the standard. This is in itself a dubious endeavour, but even if you push it to the limit, there only so much you can do. You won't be able to expose DOM APIs to a worker because that requires access to the main thread. Unless they also plan to turn the service worker into a main-thread-like context, in which case it becomes a background page.

This whole idea of getting rid of the background page is just sad.

[Chandler Davis]

Thanks for your input, everyone! Glad to see that I'm not the only one screaming into the void here. I do have another question, and I'm curious if anyone has any thoughts!

Our extension is heavily reliant on the Chrome messaging API--there are likely going to be numerous calls per second. They're very small so performance isn't a big worry. But, since these calls are happening so frequently, and the likelihood of going 5m without a call to the Messaging API is very small, wouldn't it be safe to use timeouts so long as they're less than 5m? There are some things that need a timeout/interval shorter than 1m, so the Alarms API would not be a suitable replacement. But, if I'm on the right track here, the onslaught of Messaging API calls would keep the service worker awake, and therefore make timeout/interval calls inherently reliable, right?

Of course, some fallbacks may have to be implemented in the case that the SW dies anyway, but in general I think the above would be true. What are y'alls thoughts?

[wOxxOm]

An event that's capable of waking the service worker (like sending a message or any chrome API event like chrome.tabs.onUpdated) will only prolong the worker's lifetime by 30 seconds. So in your case you should just switch to long-lived ports. However, due to a bug in ManifestV3 such port will be auto-disconnected after five minutes so you'll need to reconnect earlier by using setTimeout (example).