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