Early Design Review: Pending Beacon API

[mingyc]

Wotcher TAG!

I'm requesting a TAG review of Pending API.

This is a proposal for Pending Beacon API. It is a system for sending beacons when pages are discarded, that uses a stateful API rather than having developers explicitly send beacons themselves.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/pending-beacon/blob/main/README.md
• User research: currently only feedback from RUM providers
• Security and Privacy self-review²: https://github.com/WICG/pending-beacon/blob/main/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/pending-beacon
• Primary contacts (and their relationship to the specification):
  • Ming-Ying Chung (mingyc), Google - designing/implementing in Chrome
  • Ian Clelland (clelland), Google - specifying in Chrome
• Organization/project driving the design: Google (BFCache team)
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5690553554436096

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: https://w3c.github.io/web-performance/meetings/2022/2022-03-31/index.html
• Major unresolved issues with or opposition to this design: https://github.com/WICG/pending-beacon/issues
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mingyc and @fergald

[mingyc]

Friendly ping on this request as it has been a while.

[ylafon]

Hi, @maxpassion and I reviewed this during our F2F and we have a few questions:

About the use of Get/PostPendingBeacon, why not using the method in a dictionary instead of having two instances? How about ensuring that a PostPB isn't sent twice (like if there is a crash).
Issues about crash recovery, should it be done after a network and/or location change, as it can have privacy implications? after a time limit?
Do having a pending beacon registered impact how bfcache work?

What is the point of forcing a PendingBeacon to be sent, if it is supposed to be sent at the end of the interaction, why not using fetch or a normal beacon in that case?

Why existing mechanism is not reliable and how this new proposed mechnisam solve the not reliable issue? Should the HTML unload event be fixed instead? Could this be solved at the Page Lifecycle level instead of having a new specification?

Thanks,

[hober]

whatwg/fetch#1647

[cynthia]

We're assuming deferred fetch as proposed in whatwg/fetch#1647 will supersede this, should this be closed? @mingyc @fergald

[mingyc]

In that case, should deferred fetch be reviewed here (or in another new issue)?

[cynthia]

For this case I might recommend a new issue.

[mingyc]

Filed a Specification Review #887 as I think we have passed the early design stage.

[martinthomson]

See #887 for the review of FetchLater, which is the successor of this.