Looks reasonable to me, just wondering why the test is reporting timeout in Chrome <https://wpt.fyi/results/workers/tentative/SharedWorker-extendedLifetime.html?label=experimental&label=master&aligned>? I'm happy to approve once the test is passing.
On Wed, Apr 1, 2026 at 1:54 AM Yoav Weiss (@Shopify) <[email protected]> wrote: > Thanks for the update, and apologies for not being clearer. I meant that > it'd be good to update the WebKit position thread, as WebKit folks ended it > with "An A/B experiment could be interesting for sure as well as more > information as to which websites would want to adopt this (but would not > want to work offline)." > > If we can provide them with data that can help sway them, we should :) > > On Tue, Mar 31, 2026 at 12:47 PM Yoshisato Yanagisawa < > [email protected]> wrote: > >> Let me share the summary of origin trials as Yoav asked: >> >> Currently, 35 sites, including large and medium-scale origins, >> participated in the origin trials. Usage metrics can be found at >> https://chromestatus.com/metrics/feature/timeline/popularity/5550. >> >> Developers expressed strong interest in using this feature to maintain a >> SharedWorker's lifetime across same-origin navigations within a single tab. >> While there were requests for seamless migration from non-extended to >> extended lifetime workers, we identified a potential "footgun" regarding >> WebLocks where a long-lived worker could hold a lock indefinitely. To >> ensure safety, we decided to enforce strict separation between the two >> lifetime modes. >> >> Feedback also showed that the feature effectively handles asynchronous >> tasks after a page unloads in most scenarios. However, some sites with >> strict Content Security Policies (CSP) encountered issues when using the >> feature with blob: URLs. >> >> Notably, extended lifetime shared workers were successfully integrated >> into the HTML standard during the OT period, with positive signals from >> other browser vendors. Additionally, as we are working on enabling >> SharedWorker on Android (as discussed in a separate thread), this feature >> will also be available on Android following that rollout. To improve >> observability, chrome://inspect/#workers was updated to indicate whether a >> SharedWorker is running with the extendedLifetime flag. >> >> Please let me know if you have any questions. >> >> 2026年3月31日(火) 18:22 Yoav Weiss (@Shopify) <[email protected]>: >> >>> LGTM1 >>> >>> On Tue, Mar 31, 2026 at 8:09 AM Chromestatus < >>> [email protected]> wrote: >>> >>>> *Contact emails* >>>> [email protected], [email protected] >>>> >>>> *Explainer* >>>> >>>> https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md >>>> >>>> *Specification* >>>> >>>> https://github.com/whatwg/html/commit/9c009049e4fa9dba638ef68ca502b781082bbb68 >>> >>> >>> https://github.com/whatwg/html/pull/11600 is a slightly more convenient >>> link. >>> >>> >>>> >>>> >>>> *Summary* >>>> This update adds a new option, `extendedLifetime: true`, to the >>>> `SharedWorker` constructor. This requests that the shared worker be kept >>>> alive even after all current clients have unloaded. The primary use case is >>>> to allow pages to perform asynchronous work that requires JavaScript after >>>> a page unloads, without needing to rely on a service worker. >>>> >>>> *Blink component* >>>> Blink>Workers >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWorkers%22> >>>> >>>> *Web Feature ID* >>>> shared-workers <https://webstatus.dev/features/shared-workers> >>>> >>>> *Motivation* >>>> Many sites want to perform some work during document unloading. This >>>> usually includes writing to storage, or sending information to severs. >>>> Currently, if this work is done asynchronously (e.g., writing to IndexedDB >>>> instead of localStorage, or using CompressionStream to compress the body >>>> before sending a fetch()) the only way to do this is to use a service >>>> worker. However, requiring a service worker for this simple case of >>>> work-after-unload is heavyweight: the disk space, memory consumption, and >>>> developer experience of managing the service worker registration and >>>> lifecycle makes this hard to deploy. By using shared workers, all of these >>>> downsides are avoided. >>>> >>>> *Initial public proposal* >>>> https://github.com/whatwg/html/issues/10997 >>>> >>>> *TAG review* >>>> https://github.com/w3ctag/design-reviews/issues/1089 >>>> >>>> *TAG review status* >>>> Pending >>>> >>>> *Origin Trial Name* >>>> Extended lifetime shared workers >>>> >>>> *Goals for experimentation* >>>> None >>>> >>>> *Chromium Trial Name* >>>> SharedWorkerExtendedLifetime >>>> >>>> *Origin Trial documentation link* >>>> >>>> https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md >>>> >>>> *WebFeature UseCounter name* >>>> kSharedWorkerExtendedLifetimeFeatureEnabled >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> We intend to specify that the lifetime timeout for these shared workers >>>> be extended in the same way as service workers. Because the exact timeout >>>> of service workers is left implementation-defined, it's possible that code >>>> using this new feature could be non-interoperable. However, this has so far >>>> not proved to be a major problem in practice for service workers. >>>> >>>> *Gecko*: Positive ( >>>> https://github.com/mozilla/standards-positions/issues/1227) Some >>>> unofficial tentative positive signals and engagement in the proposal issue. >>>> >>>> *WebKit*: No signal ( >>>> https://github.com/WebKit/standards-positions/issues/492) Some >>>> unofficial tentative negative signals in the proposal issue. >>>> >>> >>> It'd be good to update that thread with OT results, as discussed. >>> >>> >>>> >>>> *Web developers*: Positive The problem of wanting to perform >>>> asynchronous work during unload is well-known, with the service worker >>>> workaround currently deployed, including by Google properties. >>>> >>>> *Other signals*: >>>> >>>> *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? >>>> *No information provided* >>>> >>>> >>>> *Debuggability* >>>> The chrome://inspect/#workers page indicates when a SharedWorker is >>>> using the extendedLifetime option. >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> No >>>> Shared workers are not yet supported on Android and Android WebView. >>>> However, we are concurrently working on enabling them there, and when we >>>> do, this feature will also be supported. >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> >>>> https://wpt.fyi/results/workers/tentative/SharedWorker-extendedLifetime.html >>>> >>>> *Flag name on about://flags* >>>> *No information provided* >>>> >>>> *Finch feature name* >>>> SharedWorkerExtendedLifetime >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Tracking bug* >>>> https://issues.chromium.org/issues/400473072 >>>> >>>> *Estimated milestones* >>>> Shipping on desktop 148 >>>> Origin trial desktop first 139 >>>> Origin trial desktop last 142 >>>> Origin trial extension 1 end milestone 145 >>>> Origin trial extension 2 end milestone 148 >>>> Shipping on Android 148 >>>> Shipping on WebView 148 >>>> >>>> *Anticipated spec changes* >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> We are currently discussing some details in preparation for >>>> specification. The exact nature of how the lifetime extension works with >>>> regard to non-window clients, particularly, has only recently reached a >>>> tentative conclusion. >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/5138641357373440?gate=4686145547665408 >>>> >>>> *Links to previous Intent discussions* >>>> Intent to Experiment: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6862683f.170a0220.16d1bf.0122.GAE%40google.com >>>> Intent to Extend Experiment 1: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68de2b1f.050a0220.58465.05c2.GAE%40google.com >>>> Intent to Extend Experiment 2: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69704662.2b0a0220.2c228a.0283.GAE%40google.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69cb650f.050a0220.201b21.039e.GAE%40google.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69cb650f.050a0220.201b21.039e.GAE%40google.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKjZaONFeBapbNDuE6qnsRDjLGQQPf2OfEmGkOLSkMnmw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKjZaONFeBapbNDuE6qnsRDjLGQQPf2OfEmGkOLSkMnmw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-P0GRAZm%3DYGWQiCwu6STTHD1S%2B2o-Oq9yTonowOum2Kw%40mail.gmail.com.
