Hi folks, This feature looks very appealing. I'd like to confirm whether it addresses the following use case:
- Page A and Page B are on the same origin and share the same SharedWorker (same URL/name). - Only a single tab is open. - The user navigates from Page A to Page B (e.g., a link click or location.href change). Previously, this navigation would briefly drop the connection count to zero, prompting the browser to terminate the worker before Page B could connect. Does this API allow the SharedWorker to remain alive across such a same-tab navigation, provided the next page re-connects within 30 seconds? Thank you, Brett On Wed, Jan 21, 2026 at 11:48 PM Yoshisato Yanagisawa < [email protected]> wrote: > Hi Alex, > > Thank you for the LGTM on the OT extension and for encouraging the early > Intent-to-Ship (I2S). I definitely share the goal of filing it soon. > > However, since the primary purpose of this extension was to secure the > crucial, large-scale performance and stability data from the major partner > (which is essential for a solid, "gapless" I2S), it's not feasible to file > it just yet—we are still in the process of gathering that key evidence. > > I am also checking with DevRel and other teams for any additional feedback > streams. I will move forward with the I2S as soon as we have the necessary > confidence and data in hand. > > Best, > Yoshisato > > 2026年1月22日(木) 1:28 Alex Russell <[email protected]>: > >> Hey Yoshisato-san, >> >> Thanks for all the care you're taking with this feature. LGTM to extend >> the OT. >> >> As discussed at this morning's API OWNERS call, I'd encourage you to send >> an Intent-to-Ship as soon as possible. This feature doesn't add any >> fundamentally new risks, and it sounds like you've already got feedback >> from some OT partners. Will this new large parntner answer fundamental >> design questions that are still left open? If no, I'd encourage you to file >> a gapless I2S as soon as possible, and certainly as soon as you have >> confidence from this latest partner about the open design questions. >> >> Best, >> >> Alex >> >> On Tuesday, January 20, 2026 at 7:32:48 PM UTC-8 Yoshisato Yanagisawa >> wrote: >> >>> Note that the spec has been discussed in the WHATUP at TPAC 2025, and >>> got positive feedback. >>> Please see: https://www.w3.org/2025/11/11-whatwg-minutes.html >>> >>> >>> 2026年1月21日(水) 12:22 Chromestatus <[email protected]>: >>> >>>> *Contact emails* >>>> [email protected], [email protected] >>>> >>>> *Explainer* >>>> >>>> https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md >>>> >>>> *Specification* >>>> *No information provided* >>>> >>>> *Summary* >>>> This 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> >>>> >>>> *TAG review* >>>> https://github.com/w3ctag/design-reviews/issues/1089 >>>> >>>> *TAG review status* >>>> Pending >>>> >>>> *Origin Trial Name* >>>> Extended lifetime shared workers >>>> >>>> *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. >>>> >>>> *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* >>>> >>>> >>>> *Goals for experimentation* >>>> *No information provided* >>>> >>>> *Reason this experiment is being extended* >>>> Developer participation in the Origin Trial has increased >>>> significantly, with most of the growth occurring since mid-September. As >>>> this momentum is recent, an extension is needed to allow developers >>>> sufficient time to conduct thorough experiments and to provide us with more >>>> comprehensive usage data and insights. To aid developers in their >>>> experimentation, we have also improved debuggability. The >>>> chrome://inspect/#workers page now indicates when a SharedWorker is using >>>> the extendedLifetime option. Separately, the standardization process is >>>> progressing well. The corresponding pull request to the WHATWG HTML >>>> specification (https://github.com/whatwg/html/pull/11600) is under >>>> review and has received positive signals, including an LGTM from Mozilla. >>>> Extending the trial will allow this real-world testing to continue while >>>> the specification solidifies. >>>> >>>> *Reason this experiment is being extended* >>>> A major partner is about to start a large-scale experiment. We believe >>>> that extending the trial to cover their experiment window is crucial, as it >>>> will provide us with essential performance metrics and stability data at >>>> scale. This extension will prevent any service disruption for the partner >>>> and ensure we have sufficient evidence to support the final launch. >>>> >>>> *Ongoing technical constraints* >>>> *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 >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Tracking bug* >>>> https://issues.chromium.org/issues/400473072 >>>> >>>> *Estimated milestones* >>>> Origin trial desktop first 139 >>>> Origin trial desktop last 142 >>>> Origin trial extension 1 end milestone 145 >>>> Origin trial extension 2 end milestone 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=6195414653075456 >>>> >>>> *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 >>>> >>>> >>>> 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/CAPNB-6XgiNMiAS44%2Bkr6ojmgmagbeVfaVz9o-JLq3Z1uhi_awA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6XgiNMiAS44%2Bkr6ojmgmagbeVfaVz9o-JLq3Z1uhi_awA%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/CALmWzr0ADXEGoscFh4uF8rz6ACSC89KZthtPnZVOBhjPL-hdbQ%40mail.gmail.com.
