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/CALmWzr1OGTeicg8SCMjTWq2mGqzibrf9u6x6neee_tRp0M6fNQ%40mail.gmail.com.
