FYI, with the several fixes, the WPT started to succeed in: https://wpt.fyi/results/workers/SharedWorker-extendedLifetime.html?label=master&label=experimental&aligned
2026年4月7日(火) 16:17 Yoshisato Yanagisawa <[email protected]>: > Sure. I will keep following up the WPTs. > > 2026年4月7日(火) 5:31 Rick Byers <[email protected]>: > >> Thank you for fixing the test. It doesn't seem reflected on wpt.fyi yet >> for some reason (even though the latest run should have it), but I'm >> confused by the history view saying it's passing. Anyway I'm happy to leave >> it to you to follow up and get wpt.fyi green. LGTM3 >> >> On Thu, Apr 2, 2026 at 4:56 AM Yoshisato Yanagisawa < >> [email protected]> wrote: >> >>> Hi Yoav and Rick, >>> >>> Thanks for the feedback. Here is an update on the two points: >>> >>> *WebKit Standards Position* >>> I’ve updated the WebKit standards-position thread with the Origin Trial >>> results and our design refinements (including the strict separation logic >>> for Web Locks safety) as Yoav suggested. >>> Link: >>> https://github.com/WebKit/standards-positions/issues/492#issuecomment-4175651351 >>> >>> *WPT Timeout Investigation* >>> I’ve identified and am now fixing (crrev.com/c/7725421) the timeout >>> issue in SharedWorker-extendedLifetime.html. I suspect the timeout was >>> caused by an unnecessary await window.pageShowPromise; in the test script. >>> This variable is not defined in the standard RemoteContext executor, >>> leading to hangs in environments like wpt.live. I’ve removed this line from >>> all related tests. >>> >>> Please let me know if there is anything else needed for the I2S. >>> >>> 2026年4月2日(木) 0:15 Rick Byers <[email protected]>: >>> >>>> 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/CAPNB-6WwQn5n_M6LLMMOOytLvsd61gC9cp6hCoKhvzf3hcgwdA%40mail.gmail.com.
