Hi everyone, I'd like to provide some context regarding the SharedWorker persistence during navigation.
To clarify, this behavior is not a regression introduced by recent BFCache changes. Rather, the recent updates corrected an inaccuracy where BFCached clients were misidentified as "active," which had been masking this behavior for a while. I’ve been aware of this long-standing issue since I took over the *Worker component (see also https://issues.chromium.org/issues/40284712). I did previously attempt to address this by implementing a 5-second survival buffer (crrev.com/c/4924910), but that approach resulted in significant test flakiness and stability issues, which is why we didn't proceed with it at that time. Looking ahead, this situation should be naturally mitigated as we roll out kFreezeSharedWorker. With that implementation, the client will be properly BFCached and frozen, and the SharedWorker will be kept alive until the client is evicted. This provides a more robust path to persistence that avoids the instability we previously encountered. Best, Yoshisato 2026年4月28日(火) 23:10 Barry Pollard <[email protected]>: > I think this is basically if you have one constructor with > `extendedLifetime: true` and another constructor for the same worker > without that option, then ideally the browser could share those workers and > upgrade to an extended lifetime one if the non-extended happened first. > Especially during the changeover when introducing extendedLifetime for the > first time. > > However, there are some footguns that get worse with extendedLifetime > shared workers (see > https://github.com/whatwg/html/issues/10997#issuecomment-3105509844). > Therefore it's safer to not combine these two separate invocations and > instead "enforce strict separation between the two lifetime modes.", which > I believe from > https://github.com/whatwg/html/issues/10997#issuecomment-2791533299 is > done with option 4 out of the solutions proposed: > > 4. Only the first new SharedWorker() invocation controls the lifetime. >> All others have to match, and if they don't match, we throw an exception or >> fail the worker creation. > > > On Tue, 28 Apr 2026 at 14:44, Jake Archibald <[email protected]> > wrote: > >> Ohh interesting! But now I'm confused about the email I was replying to, >> which seemed to suggest that the lack of continuity was intentional, due to >> a "footgun"? >> >> On Tue, 28 Apr 2026 at 14:32, Barry Pollard <[email protected]> >> wrote: >> >>> This looks like a regression introduced in Chrome 146 due to some >>> unrelated work on bfcache. I've raised >>> https://issues.chromium.org/issues/507358432 for this. >>> >>> On the plus side the new `extendedLifetime: true` option does >>> reintroduce this functionality for sites happy to use this :-) >>> >>> But we should fix that regression so it also works for same-origin >>> navigations for workers without that option. And ideally introduce a WPT to >>> catch this next time (I couldn't see an exiting one that is broken in >>> stable >>> <https://wpt.fyi/results/workers/shared-worker-options-mismatch.html?label=stable&label=master&aligned> >>> and working in experimental >>> <https://wpt.fyi/results/workers?label=master&label=experimental&aligned>) >>> to ensure continued interop as you say. >>> >>> On Tuesday, April 28, 2026 at 1:01:17 PM UTC+1 [email protected] >>> wrote: >>> >>>> On Tuesday, 31 March 2026 at 11:47:41 UTC+1 [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. >>>> >>>> Does this mean Chrome has no intention of implementing the spec'd >>>> behaviour >>>> <https://html.spec.whatwg.org/multipage/workers.html#between-loads-shared-worker-timeout> >>>> here? Both Firefox and Safari maintain a single shared worker across >>>> navigations. It would be nice to have some interop here. >>>> >>>> Demo: https://random-stuff.jakearchibald.com/shared-worker-navigation/ >>>> (the number is the same every navigation in Firefox and Safari, but not in >>>> Chrome, since the worker is re-created each time). >>>> >>>> Jake. >>>> >>>> -- 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-6VraFzAYeSBH5CLO2CjKdnAHogoRDRDqjXuoOeTuLosHg%40mail.gmail.com.
