How does this feature interact with service workers? Will it trigger a FetchEvent to be fired in the worker thread?
I expect we probably want this feature to bypass service workers and not fire a FetchEvent. Otherwise this is an avenue for background SW processing which has privacy and abuse risks. On Mon, May 9, 2022 at 8:01 AM Darren Willis <[email protected]> wrote: > Contact [email protected] > > Explainer > https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md > > Specification > > Summary > > A stateful API for beacons that has the browser control the time beacons > are sent. 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. (Handlers such as 'unload' are often ignored, for > example.) This API delegates the sending to the browser itself, so it can > support beacons on page unload or on page hide, without the developer > having to implement send calls at exactly the right times. > > > Blink componentBlink > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> > > 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. There are currently four major > methods of beaconing used around the web; all suffer from reliability > problems, stemming from one core issue: There is not an ideal time in a > page’s lifecycle to make the Javascript call to send out the beacon. > ‘unload’ and ‘beforeUnload’ are unreliable (and outright ignored by several > major browsers), and pageHide and visibilityChanged have issues on mobile > platforms. To simplify this issue and make beaconing more reliable, we > propose adding a stateful Javascript API where a page can register that it > wants a beacon (or beacons) issued when it unloads or the page is hidden. > Developers can populate beacon(s) with data as the user uses the page, and > the browser ensures beacon(s) are reliably sent at some point in time. This > frees developers from worrying about which part of the page lifecycle to > send their beacon calls in. > > > Initial public proposal > https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776 > > TAG review > > TAG review statusPending > > Risks > > > Interoperability and Compatibility > > > > Gecko: No signal > > WebKit: No signal > > Web developers: No signals > > Other signals: > > WebView application risks > > No > > Debuggability > > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?No > > Flag namePendingBeaconAPI > > Requires code in //chrome?False > > Estimated milestones > > No milestones specified > > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5690553554436096 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > -- > 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/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjjWrtCKtp2WSrKwrAbdakGuzUwGbswBRT1ADExV3%3DrsQ%40mail.gmail.com.
