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-6Xf%3DfSbC6XLfcLLn2AV3naoqZ3kK5g6s%3DAyQwM0gFsuqQ%40mail.gmail.com.
