Hi Brett and folks, Thank you for raising this critical deployment issue. I must admit regret for previously confirming that the extendedLifetime option could solve the same-origin navigation problem. The fail on mismatch policy (Option 4) is fundamentally necessary to prevent the "Web Lock footgun," where a long-lived worker could hold a lock indefinitely. (Please see: https://github.com/whatwg/html/issues/11520#issuecomment-4028378675)
Adopting any of your suggested alternatives (Options 1, 2, or 3) would compromise this essential safety mechanism. Allowing pages unprepared for the extended lifetime to connect would significantly increase the Web Lock risk, undermining the feature's core design goal. Therefore, I cannot safely apply any of these options. Could you suggest alternative approaches that mitigate the Web Lock footgun while still addressing the practical deployment challenges you face? Best regards, Yoshisato 2026年3月21日(土) 5:14 Brett McStotts <[email protected]>: > Option 2 would be the most ideal in my opinion. > > On Fri, Mar 20, 2026 at 3:53 PM Brett McStotts <[email protected]> > wrote: > >> Hey folks, >> >> I see a practical blocker with Option 4 (fail on mismatch) >> <https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#mismatched-expectedlifetime-options> >> . >> >> When Page A uses { extendedLifetime: true } and a user navigates to Page >> B (which doesn't set it), Page B fails to connect to the existing shared >> worker. This breaks Page B entirely. >> >> This is unavoidable in real deployments. Different WebApps using the same >> Shared Worker may have different deployment pipelines. Web apps also ship >> incremental updates — not every page adopts extendedLifetime simultaneously >> if the deployment is not "sticky". Worse, users keep stale tabs open. >> Different teams owning different apps would need to perfectly synchronize >> every app and cached resource across multiple production deployments, which >> is unrealistic for many large organizations. >> >> One workaround would be to use differently-named SharedWorkers to avoid >> the mismatch, but that means running multiple SharedWorkers. This >> reintroduces the same operational burden a heavyweight service worker has — >> the very problem this feature is trying to solve. It also adds >> unpredictable behavior and potentially increased server load from duplicate >> API calls across workers that should have been shared. >> >> Option 1 (any client can extend) or Option 3 (first client wins, >> mismatches ignored with console warning) would both be safe, >> forward-compatible, and actually shippable in production. I understand >> Option 4 was chosen for consistency with how type and credentials behave on >> the SharedWorker constructor; however, this feature has a core use case of >> sharing a worker across navigations and across apps. A mismatch in type or >> credentials means clients genuinely disagree about how the worker should >> run. A mismatch in extendedLifetime just means they disagree about cleanup >> timing, which shouldn't prevent connection in my humble opinion. >> >> Please reconsider. >> >> Thank you, >> >> Brett McStotts >> >> On Mon, Mar 16, 2026 at 7:48 AM Yoshisato Yanagisawa < >> [email protected]> wrote: >> >>> Hi, >>> >>> Thanks for having the interest in the feature. >>> Yes. I made >>> https://sharedworker-extendedlifetime.netlify.app/subdirectory/other.html >>> for testing the behavior. Please fill out the values, and push the "Visit >>> Top Page" button. >>> >>> Regards, >>> Yoshisato. >>> >>> >>> 2026年3月14日(土) 6:13 Brett McStotts <[email protected]>: >>> >>>> 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/CAPNB-6UKxytAM35QY%2BS1NzfXA3nQZkSXRh_skbFKwicc1c6%2B2w%40mail.gmail.com.
