Intent to Prototype: Declarative PendingBeacon API

[Darren Willis]

Contact emails

d...@chromium.org

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 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 status

Pending

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?

No

Flag name

PendingBeaconAPI

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.

[Ben Kelly]

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.

--
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+...@chromium.org.
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.

[Darren Willis]

Sorry for the late reply. Agreed that we'll want this feature to bypass service workers, I'll add this to the explainer.