Thanks for working on this!! (and iterating on the solution based on feedback)
On Tue, Jul 18, 2023 at 4:23 AM Ming-Ying Chung <[email protected]> wrote: > 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 [email protected] > [email protected] > [email protected] > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWnfOwJjU9yG47FM3u0O1XuzjCiRutiHFpE2QCw3Mqf%3Dg%40mail.gmail.com.
