Android shared workers

[Rik Cabanier]

One of our users reported that sharedworkers weren't working in the browser.

After investigating it looks like they were never supported on Android but it seems that they are supported everywhere else, including mobile Safari.

Reading https://monorail-prod.appspot.com/p/chromium/issues/detail?id=154571, it seems there was a concern that too many sharedworkers would exhaust system resources. Is that still a concern 10 years later?

[Ben Kelly]

FWIW, chrome on android is the last holdout on shared workers.  Safari on ios supports it.  It would be nice if this could be prioritized.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34528104-dca4-4a21-b376-013bd393dfc1n%40chromium.org.

[Kenji Baheux]

Compelling use cases (e.g. actual & reasonably popular products that work better or only work when sharedworker are available on mobile) would help boost the priority over other interop requests.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjH%2BV42hygYZTH6f9CBj4nfkk4W4rQuaXY84d-r%2BX%3DOmg%40mail.gmail.com.

[Ben Kelly]

On Thu, Oct 19, 2023 at 5:20 AM Kenji Baheux <kenji...@chromium.org> wrote:

Compelling use cases (e.g. actual & reasonably popular products that work better or only work when sharedworker are available on mobile) would help boost the priority over other interop requests.

There were enough use cases for Apple to reintroduce shared worker after removing it.  Classic one is any kind of site where a user may plausibly have multiple tabs open and need them to remain in sync with the server.  You treat the SharedWorker as the source of truth in terms of talking to the server, data updates, etc.  So email clients, shared document editors, etc fit this bill.  Yes, you can accomplish the same thing more awkwardly other ways with leader-election algorithms using BroadcastChannel or force ServiceWorker into a SharedWorker model by forcing it to stay alive.  But forcing sub-optimal solutions is a tax on the web ecosystem for these use cases and pushes people to build native apps for mobile instead of the web.

I'll also just say I find the framing of "mobile web" as a separate platform from the web in general or desktop web somewhat surprising and disappointing.  We should not be bifurcating the web ecosystem without a good reason.   What is the reason SharedWorker should be desktop-only when every other browser is able to ship it on mobile?

[Kenji Baheux]

On Thu, Oct 19, 2023 at 10:56 PM Ben Kelly <wande...@chromium.org> wrote:

On Thu, Oct 19, 2023 at 5:20 AM Kenji Baheux <kenji...@chromium.org> wrote:

Compelling use cases (e.g. actual & reasonably popular products that work better or only work when sharedworker are available on mobile) would help boost the priority over other interop requests.

There were enough use cases for Apple to reintroduce shared worker after removing it.  Classic one is any kind of site where a user may plausibly have multiple tabs open and need them to remain in sync with the server.  You treat the SharedWorker as the source of truth in terms of talking to the server, data updates, etc.  So email clients, shared document editors, etc fit this bill. 

  Yes, you can accomplish the same thing more awkwardly other ways with leader-election algorithms using BroadcastChannel or force ServiceWorker into a SharedWorker model by forcing it to stay alive.  But forcing sub-optimal solutions is a tax on the web ecosystem for these use cases and pushes people to build native apps for mobile instead of the web.

I'll also just say I find the framing of "mobile web" as a separate platform from the web in general or desktop web somewhat surprising and disappointing.  We should not be bifurcating the web ecosystem without a good reason. 

At the time there was a reasonable reason (complexity and implementation costs vs. lack of strong use cases / partners).

Things are a bit different these days. That said, there are other interop requests that compete for the team's bandwidth, beside their main projects. The other requests have clearer signals of impact at the moment.

 

 What is the reason SharedWorker should be desktop-only when every other browser is able to ship it on mobile?

To be clear, no one said that SharedWorker should be desktop-only.

This is not an if, it's a when.

[Christian Stewart]

All,

On Friday, October 20, 2023 at 2:01:30 AM UTC-7 Kenji Baheux wrote:

Things are a bit different these days. That said, there are other interop requests that compete for the team's bandwidth, beside their main projects. The other requests have clearer signals of impact at the moment.

 

 What is the reason SharedWorker should be desktop-only when every other browser is able to ship it on mobile?

To be clear, no one said that SharedWorker should be desktop-only.

This is not an if, it's a when.

SharedWorker is powerful for sharing resources (connections) between multiple tabs.

At the moment I am facing adding unnecessary complexity with leader election and broadcast channels specifically for the Android Chrome browser to emulate SharedWorker as currently it is the only major browser to not support this:  https://caniuse.com/sharedworkers - while Firefox Mobile and Safari Mobile both support it.

I understand that this feature competes for time with other more important requests.

With that in mind, I'd like to politely request that this issue be re-visited soon, so that we can avoid having to implement complex workarounds for lack of SharedWorker on Chrome for Android, and unlock the performance improvements of cross-tab resource sharing on mobile.

Thanks!

Christian Stewart

[xxai art]

I used SharedWorker to reuse websocket connections, 

and then I found that chrome on Android does not support this (but firefox does)

[Thomas Danecker]

Hello,

SharedWorker seems to be the only way to store OAuth 2.0 access tokens securely in browser sessions and share them between tabs.

See for example the best practices described here: https://auth0.com/docs/secure/security-guidance/data-security/token-storage

Any other solutions (e.g. using sessionStorage) either expose the access token to XSS attacks or do not allow to share it between tabs (in-memory storage in javascript closures).

Best,

Thomas Danecker