Intent to Experiment: SharedWorker on Android

[Chromestatus]

Contact emails

yyana...@google.com, dom...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/workers.html#shared-workers-and-the-sharedworker-interface

Summary

For a long time, SharedWorker has been disabled on Android due to concerns about its unpredictable process lifecycle. We believed that SharedWorker instances might terminate unexpectedly, without noticing to users or web developers, which we considered unacceptable. However, a recent discussion on GitHub (https://github.com/whatwg/html/issues/11205) suggests that the unpredictable nature of SharedWorker's process lifecycle might not be as significant an issue as we once thought. Based on this, we plan to re-enable SharedWorker on Android while simultaneously investigating this behavior to ensure a stable and reliable experience.

Blink component

Blink>Workers

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

While Chrome has been the sole major browser not to offer SharedWorker, this change aims to close that gap. However, unlike on desktop, Android's unpredictable process lifecycle presents a unique risk. SharedWorker instances might terminate unexpectedly, for example, when a Chrome app is moved to the background and then foregrounded. This inherent uncertainty in the Android environment is a key risk when running SharedWorker.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive As you can see in http://crbug.com/40290702, SharedWorker support on Android has been a long-awaited feature by web developers. This demonstrates a clear and sustained demand from the developer community for this capability.

Other signals:

Ergonomics

n/a

Activation

n/a

Security

This feature is already shipped on desktop, and no new security risks are introduced with the Android implementation.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Ongoing technical constraints

None.

Debuggability

This feature is already shipped on desktop, and no new debuggability issues should be introduced with the Android implementation.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

This aims to make SharedWorker supported on Android and Android WebView. SharedWorker has been supported other than them.

Is this feature fully tested by web-platform-tests?

Yes

SharedWorker tests under https://wpt.fyi/results/workers. e.g. https://wpt.fyi/results/workers/SharedWorker-simple.html Note that since wpt.fyi runs tests on Linux not Android for Chromium.

DevTrial instructions

https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker/SharedWorker

Flag name on about://flags

None

Finch feature name

SharedWorker

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40290702

Measurement

SharedWorkerStart filtered by Android.

Estimated milestones

Origin trial Android first	140
Origin trial Android last	144
DevTrial on Android	140

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6265472244514816?gate=5096285778214912

This intent message was generated by Chrome Platform Status.

[Yoshisato Yanagisawa]

Not sure why the Experiment Goals became empty, but let me copy contents from chromestatus.

2025年7月18日(金) 12:25 Chromestatus <ad...@cr-status.appspotmail.com>:

Experiment Goals

The goal is to evaluate the real-world impact of Android's process lifecycle on SharedWorker stability. Unlike on desktop, SharedWorker instances on Android can be terminated unexpectedly by the operating system due to memory pressure. This trial allows us to release the feature to developers who understand this risk and can provide crucial feedback. Specifically, we aim to measure: 1. The frequency of unexpected SharedWorker terminations in real-world scenarios. 2. Whether the current API is sufficient for developers to handle such terminations gracefully. 3. The necessity of potential spec-level countermeasures, as discussed in https://github.com/whatwg/html/issues/11205, to bridge this behavioral gap between mobile and desktop platforms and ensure a consistent developer experience. The insights from this experiment will be critical in determining the path to shipping SharedWorker on Android, informing whether it can be enabled by default or if further mitigation work is required.

Experiment Risks

The risk for sites participating in this experiment is functional breakage upon the trial's conclusion. When the trial period ends, the SharedWorker API will be disabled on Chrome for Android, pending the results of the experiment. Consequently, any site that has integrated SharedWorker-based logic for its Android users will experience failures, as the SharedWorker constructor will no longer be available.

[Mike Taylor]

LGTM

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6V3xrSzQwRgTAUM_tAX5AasCdEyAbhaAHVTKc9m%2BagnGg%40mail.gmail.com.

[Jason Robbins]

This OT has not started yet, but it is already triggering alerts to the interop-tooling team about high usage, probably because its usecounter is counting usage on platforms that already support this feature.  https://chromestatus.com/metrics/feature/timeline/popularity/5

That chart goes up to 1.6%, which is more than the 0.5% ratio at which a limit is nominally supposed to be enforced, according to https://g3doc.corp.google.com/chrome/origin_trials/g3doc/trial_usage_monitoring.md#investigating-alerts.

Should we set a higher alert limit for this OT and have it continue to use the existing usecounter?

Or, should the feature owner define a new usecounter to count new usage separately from existing usage?

Or, something else?

Thanks,

jason!

[Yoshisato Yanagisawa]

Let me also write a reply here.  Since nobody uses SharedWorker on Android now, I thought we can know the OT number by filtering with a platform.  However, I am not sure how feasible it is.

In case it is not feasible, I have also written a change list to add a dedicated use counter for SharedWorkerOnAndroid.

https://chromium-review.googlesource.com/c/chromium/src/+/6818096

I am open to going either way.

1. add a new dedicated counter.

2. higher alert limit (maybe current average value + the OT limit)

3. filter by platform.

4. anything else.

Thank you,

Yoshisato.

2025年8月1日(金) 2:58 Jason Robbins <jrob...@google.com>:

[Jason Robbins]

For the record, the OT is now using the SharedWorkerOnAndroid usecounter and the high usage alert has stopped.  Thanks for helping resolve this issue.

Thanks,

jason!