The exact last-window behavior is not currently interoperable across shipping browsers. Fetch’s keepalive semantics allow a request to outlive its initiating document, but do not require the browser application itself to remain alive during shutdown, so this is still best-effort rather than a delivery guarantee.
For WebKit, I am carrying Yoav’s implementation of fetchLater(): https://github.com/WebKit/WebKit/pull/73271 That implementation explicitly tests delivery after the last WKWebView is closed, including with an ephemeral data store. The PR is still open, so this is intended alignment rather than behavior available in Safari today. Getting it through WebKit review, EWS, and any additional splitting may take some time. Firefox supports fetch(..., {keepalive: true}) and Mozilla has a positive standards position on fetchLater(), but fetchLater() itself is not implemented yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1936180 There is also an existing Firefox bug for beacons being dropped when the browser closes: https://bugzilla.mozilla.org/show_bug.cgi?id=1609653 So, as far as I can tell, Chrome will initially be the only shipping browser with this explicit last-window lifetime handling. WebKit work is underway toward similar behavior; Firefox is supportive of the API, but does not currently have the equivalent implementation. Once the WebKit work is done, I would also be happy to give the Firefox implementation a try. No promises, though, I am still a Chromium guy at heart. :) Am Mi., 9. Sept. 2026 um 23:48 Uhr schrieb Mike Taylor < [email protected]>: > Can you speak to the interop situation here? Will this only work in > Chrome, or do other browsers already do this? > On 9/9/26 3:56 p.m., Helmut Januschka wrote: > > On desktop Chrome, we are enabling a change that keeps the browser process > and relevant profile alive while fetch(..., {keepalive: true}) or > fetchLater() requests are pending. This allows those requests to complete > when the last tab in the last browser window closes, instead of being > dropped: > > https://issues.chromium.org/issues/408010432 > > The hold lasts only while requests are pending. Existing keepalive request > quotas and timeouts continue to apply. Android behavior is unchanged. > > Implementation: > https://chromium-review.googlesource.com/c/chromium/src/+/8181986 > Default-on CL: > https://chromium-review.googlesource.com/c/chromium/src/+/8382658 > > No action is required from web developers. > > -- > 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/bb27f5ec-1546-4142-bfce-ff375e3da300n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb27f5ec-1546-4142-bfce-ff375e3da300n%40chromium.org?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/CAFmjHKRCBdCNVEvEFubfEN9KD1duFTUBbN3YgU25Qqgp%2BPPucQ%40mail.gmail.com.
