fetchLater() API

[mingyc]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: fetchLater() API
• Specification or proposal URL: https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
  • PR Deferred fetching whatwg/fetch#1647
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1936180
• Mozillians who can provide input (optional):
• WebKit standards-position: fetchLater() API (previously: PendingBeacon API) WebKit/standards-positions#85

Other information

• ChromeStatus: https://chromestatus.com/feature/5690553554436096

We would like to have feedback from WebKit about this API before finalizing its shape and behavior.

[sefeng211]

I don't know how other folks feel. My feeling is that without fixing the unable to send beacon when browser closes/crashes issue, this is more like moving from a 50% broken API to a 25% broken API.

[valenting]

I don't know how other folks feel. My feeling is that without fixing the unable to send beacon when browser closes/crashes issue, this is more like moving from a 50% broken API to a 25% broken API.

I agree. I don't quite understand why we actually need this: Robustness against crashes/forced terminations/network outages.
If a beacon is to be sent after a forced termination caused by shutdown, the beacon might be sent days after it's registered, severely limiting its usefulness.

Also considering the motivation - if the major UAs had a good web-compat story for page-visibility, would pending beacon still be necessary?

[mingyc]

I agree. I don't quite understand why we actually need this: Robustness against crashes/forced terminations/network outages.

Crash recovery is discussed in WICG/pending-beacon#34. It's very likely that this will be blocked due to privacy restriction, no matter it's useful or not.

The usefulness is also mentioned in TPAC meeting though. The origin movitaion was just to provide some browser-guarantee behavior for this new API.

if the major UAs had a good web-compat story for page-visibility, would pending beacon still be necessary?

This new API's default behavior is send-on-page-discard, which is different from the existing navigator.sendBeacon(). To achieve it, non of the existing page event is suitable for this purpose: see https://github.com/WICG/pending-beacon#problem-and-motivation

[fergald]

Crash recovery is really going to be up to the implementation. If you assume that after a crash, the browser reopens with all of the same tabs then it will be OK to just immediately send all the beacons that had been queued (based on the privacy rule that it's always OK to send for site X as long as there is a live instance of site X in the browser). If the browser does not reopen previous tabs, it can send those beacons as soon as the user visits the site in question (or as soon as a service worker starts for that site).

There is also an argument that if background-sync is enabled then it's always OK to send any beacon. We haven't pushed hard on that argument. The "live instance" argument above is easy because any site could achieve the same using IndexedDB and JS.

@sefeng211 Given that, do you consider the result to be 25% broken? Would you feel differently if we gated on background sync instead of live instance?

the beacon might be sent days after it's registered

True or it might be sent quite soon after. The worst case scenario does not seem like the right thing to look at.

sendBeacon right now drops some fraction of requests even without a shutdown or full browser crash and this would do better. We should have some data from our origin trial soon.

Unrelated to reliability, sendBeacon is the last legitimate use of unload handlers (that we can think of). Unload handlers are a major blocker of BFCache usage on Chrome and Mozilla.

[mingyc]

@sefeng211 @valenting pinging for any updates or comments

[mingyc]

Ping again for your position on this API.

[sefeng211]

Sorry about the silence!

This new API's default behavior is send-on-page-discard, which is different from the existing navigator.sendBeacon(). To achieve it, non of the existing page event is suitable for this purpose: see https://github.com/WICG/pending-beacon#problem-and-motivation

So Valentin had asked this and I want to double check...I am not sure if this answered the original question. If we no longer have the issues listed in w3c/page-visibility#59, then sendBeacon becomes reliable right? And Do we still benefit something from the PendingBeacon API?

@sefeng211 Given that, do you consider the result to be 25% broken? Would you feel differently if we gated on background sync instead of live instance?

Yeah, I guess I am still skeptical about the usefulness of this API. Since the crash recovery stuff is still under discussion, I don't think I'd count that as a feature of this API.

[zcorpan]

Per https://groups.google.com/a/chromium.org/g/blink-dev/c/oU1yt5cdGH8?pli=1 this would help with getting rid of the unload event and therefore make more pages eligible for bfcache. cc @smaug---- @petervanderbeken

[smaug----]

I'm having trouble to understand what the proposal is currently. The explainer talks about extending Fetch API with DeferSend, but the spec proposal has very different API.

[fergald]

@smaug----

The spec change hasn't been updated in a long time. There is not much point in updating the spec until we have consensus on the explainer.

@mingyc if the explainer still links to the spec PR, maybe remove that for now.

[mingyc]

Sorry about the confusion. In the latest version of explainer, the link to spec has been removed.

@smaug---- @zcorpan FYI we have recently moved toward fetch-based API design, and there are questions about API shape pending discussions. Please take a look and give us feedback. Thanks! https://github.com/WICG/pending-beacon/issues?q=is%3Aissue+is%3Aopen+label%3Afetch-based-api

[mingyc]

Note: the PendingBeacon API has been evolved to a fetch-based approach, and the latest discussions happen in whatwg/fetch#1647