Hi Team, We plan to prototype the fetchLater API, which is the successor of the previous PendingBeacon API (intent to prototype mail <https://groups.google.com/a/chromium.org/g/blink-dev/c/tPTRZkSmlbg/m/5vGhjrEsAgAJ>, intent to OT mail <https://groups.google.com/a/chromium.org/g/blink-dev/c/ZCVcUEYzVHs/m/3PjKPLmkAQAJ>). The fetchLater API is the result of discussion <https://github.com/WICG/pending-beacon/issues/70> with users and other browser vendors.
Contact emailsm...@chromium.org denom...@chromium.org pending-beacon-experim...@google.com Explainer https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md Chromium Design Doc https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ Specification https://whatpr.org/fetch/1647/094ea69...152d725.html#fetch-later-method (draft PR) Summary fetchLater() is a JavaScript API to request a deferred fetch. Once requested, the deferred request is queued by the browser, and will be invoked in one of the following scenarios: - The document is destroyed. - The document is bfcached and not restored after a certain time. The API returns a FetchLaterResult that contains a boolean field sent that may be updated to tell whether the deferred request has been sent out or not. On successful sending, the whole response will be ignored, including body and headers. Nothing at all should be processed or updated, as the page is already gone. Note that from the point of view of the API user, the exact send time is unknown. Blink componentBlink>Network>FetchAPI <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EFetchAPI> Motivation Web developers have a need for ‘beaconing’ - that is, sending a bundle of data to a backend server, without expecting a particular response, ideally at the ‘end’ of a user’s visit to a page. Existing beacon APIs are all based around a developer constructing and sending a beacon, and there's no good time for that "send" call to be made. This API delegates the sending to the browser itself, so it can support requests on page unload or on page hide, without the developer having to implement send calls at exactly the right times. Initial public proposal https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776 TAG review TAG review statusPending <https://github.com/w3ctag/design-reviews/issues/776> (for PendingBeacon, not fetchLater) Risks Interoperability and Compatibility Gecko: Pending <https://github.com/mozilla/standards-positions/issues/703> WebKit: Supportive <https://github.com/WebKit/standards-positions/issues/85> Web developers: No signals Other signals: WebView application risks No Debuggability fetchLater requests should be shown in the DevTool's network tab, similar to other network requests. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?Not yet. But there are tests for PendingBeacon to convert from. Flag nameFetchLaterAPI Requires code in //chrome?False Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5690553554436096 (old entry for PendingBeacon API) -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3JASXx4qJi2Hnac0Xv%3DinTxQ%3DWSrYFO5hcjZbE6vRbotOgUg%40mail.gmail.com.
