[blink-dev] Intent to Experiment: Declarative Beacon API

328 views
Skip to first unread message

Ming-Ying Chung

unread,
Jun 17, 2022, 1:03:08 PM6/17/22
to blink-dev, Fergal Daly, Daisuke Enomoto, Rakina Zata Amni, Kentaro Hara, Yuzu Saijo

Contact emails

my...@chromium.org, fer...@chromium.org, deno...@chromium.org


Explainer

https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md


Specification

https://clelland.github.io/page-unload-beacon/spec.html (In draft state)


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


TAG review

None yet.


TAG review status

N/A


Risks



Interoperability and Compatibility



Gecko: No signal


WebKit: No signal


Web developers: No signals


Other signals:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Goals for experimentation

The intent is for experiments to learn that developers can easily adopt the API shapes to achieve current use cases in addition to getting feedback from them. The experiment also aims to test the stability and reliability of the API.


Ongoing technical constraints

In M104, the API described in the explainer is not yet fully developed, such that the API

  • Supports only the GET method. Setting it to POST will fall back to GET.

  • Does not support request payload, i.e. it does not send out data set by setData(data).

  • Does not support pageHideTimeout.

  • Does not recover from browser crashes, forced closures, network failure, etc.


Debuggability

There are no particular debugging APIs made available or Chrome DevTools integrations for this OT. We plan to build an integration with Chrome DevTools to provide a better developer experience. This OT will allow us to get feedback that helps us build the right design.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

No, basic tests are present and we will be adding more as we complete more of the implementation.


Flag name

PendingBeaconAPI


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1293679


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1323615


Estimated milestones

M104 for off-by-default experiment



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5690553554436096


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com



This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Jun 17, 2022, 1:57:45 PM6/17/22
to Ming-Ying Chung, blink-dev, Fergal Daly, Daisuke Enomoto, Rakina Zata Amni, Kentaro Hara, Yuzu Saijo
On 6/17/22 10:59 AM, Ming-Ying Chung wrote:

Contact emails

my...@chromium.org, fer...@chromium.org, deno...@chromium.org


Explainer

https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md


Specification

https://clelland.github.io/page-unload-beacon/spec.html (In draft state)


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


TAG review

None yet.

I'd recommend filing a TAG review as well as asking for signals now, to allow folks plenty of time to respond.
Just to confirm, the request is only for a single milestone (104)?

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5690553554436096


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com



This intent message was generated by Chrome Platform Status.

--
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/CAH3JASV7pR%3D3poOA0x2sQgVLOobtjCyfxLE3kYsnasfBVSyOEg%40mail.gmail.com.


Frederik Braun

unread,
Jun 19, 2022, 4:20:15 PM6/19/22
to blin...@chromium.org
FWIW the term "Declarative" is often used for features implemented in
HTML (e.g. Declarative Shadow DOM) and the naming here seems a bit
confusing and misled me for a bit.

The wicg draft title "page unload beacon" seems much less so.

Fergal Daly

unread,
Jun 20, 2022, 12:31:51 AM6/20/22
to Mike Taylor, Ming-Ying Chung, blink-dev, Daisuke Enomoto, Rakina Zata Amni, Kentaro Hara, Yuzu Saijo
Sorry, there were some details left out of this I2E. We actually have a lot of signals from web devs on this. There are some comments on


but we also presented this to W3C WebPerf with a lot of positive signals. Minutes are here from the most recent one.

We don't have any reaction from Mozilla or WebKit that I know of and we will file a TAG request shortly,

F

Joe Medley

unread,
Jun 21, 2022, 1:42:15 PM6/21/22
to Fergal Daly, Mike Taylor, Ming-Ying Chung, blink-dev, Daisuke Enomoto, Rakina Zata Amni, Kentaro Hara, Yuzu Saijo
What's an 'off by default experiment'? Are you adding an item to chrome://flags or is it something else?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


Mike Taylor

unread,
Jun 24, 2022, 9:36:15 AM6/24/22
to Fergal Daly, Ming-Ying Chung, blink-dev, Daisuke Enomoto, Rakina Zata Amni, Kentaro Hara, Yuzu Saijo
Thanks - sounds good.

Could you clarify the desired experiment timeline? Is it just for M104, or something else?

Caleb Raitto

unread,
Jun 27, 2022, 4:17:50 PM6/27/22
to blink-dev, mike...@chromium.org, my...@chromium.org, blink-dev, deno...@chromium.org, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Hi, I filed https://github.com/darrenw/docs/issues/3 about a time limit on the duration from bfcache page freeze to beacons being sent -- could you PTAL?

Thanks, 
-Caleb

Daisuke Enomoto

unread,
Jun 27, 2022, 10:14:25 PM6/27/22
to Caleb Raitto, mike...@chromium.org, Joe Medley, blink-dev, my...@chromium.org, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Joe, the API is behind the flag "PendingBeaconAPI".

Mike, we came to discuss the new ideas of API design after we sent this I2E. We will update the I2E thread when we have clarity on the design discussion and the timeline when an experiment can start. 

Caleb, thank you for filing an issue.

Mike Taylor

unread,
Jun 28, 2022, 8:38:57 AM6/28/22
to Daisuke Enomoto, Caleb Raitto, Joe Medley, blink-dev, my...@chromium.org, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Sounds good - we'll consider this Intent paused until we hear otherwise.

Daisuke Enomoto

unread,
Jun 28, 2022, 9:18:25 AM6/28/22
to Mike Taylor, Caleb Raitto, Joe Medley, blink-dev, my...@chromium.org, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Thank you for your understanding. We'll update the thread as soon as we have clarity on API design and experiment timeline.

Joe Medley

unread,
Jun 28, 2022, 10:23:59 AM6/28/22
to Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, my...@chromium.org, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Daisuke,

That makes it either a dev trial or an origin trial. Since you've recorded a value for origin_trial_feature_name in runtime_enabled_features.json5 that makes it an origin trial. I assume that's starting in 105?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Ming-Ying Chung

unread,
Aug 31, 2022, 3:04:09 AM8/31/22
to Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Hi all,

Reviving this thread as we plan to conduct an Origin Trial for this feature in M106, with the following updates. Please take a look.

Ian Clelland

unread,
Sep 2, 2022, 4:40:29 PM9/2/22
to Ming-Ying Chung, Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
On Wed, Aug 31, 2022 at 3:04 AM Ming-Ying Chung <my...@chromium.org> wrote:
Hi all,

Reviving this thread as we plan to conduct an Origin Trial for this feature in M106, with the following updates. Please take a look.

Is it possible to extend this trial for a few releases? Most trials run for ~3 releases initially, and I think that would be useful here. I know of a number of external partners, eager to test the API, who might need more than a single release to be able to deploy this and get back sufficient data for constructive feedback.


 

Ming-Ying Chung

unread,
Sep 5, 2022, 10:02:45 PM9/5/22
to Ian Clelland, Ming-Ying Chung, Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Hi Ian,

There is no concern from the dev team. We can try to run the OT from M106 to M108 if possible.

Yoav Weiss

unread,
Sep 6, 2022, 1:18:57 AM9/6/22
to Ming-Ying Chung, Ian Clelland, Ming-Ying Chung, Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
LGTM to experiment M106-108 inclusive 

Yoav Weiss

unread,
Sep 7, 2022, 4:49:08 AM9/7/22
to Ming-Ying Chung, Ian Clelland, Ming-Ying Chung, Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Sure, LGTM still stands.

On Wed, Sep 7, 2022 at 10:48 AM Ming-Ying Chung <my...@google.com> wrote:
Hi Ian & Yoav,

We might have to delay the OT to M107-M109 as we still have several issues to solve. Could it be updated?

Ming-Ying Chung

unread,
Sep 7, 2022, 10:52:22 AM9/7/22
to Yoav Weiss, Ian Clelland, Ming-Ying Chung, Joe Medley, Daisuke Enomoto, Caleb Raitto, mike...@chromium.org, blink-dev, rak...@chromium.org, Kentaro Hara, yu...@chromium.org, Fergal Daly
Hi Ian & Yoav,

We might have to delay the OT to M107-M109 as we still have several issues to solve. Could it be updated?

On Tue, Sep 6, 2022 at 2:18 PM Yoav Weiss <yoav...@chromium.org> wrote:
Reply all
Reply to author
Forward
0 new messages