Update API spec in explainer to match latest discussion

WICG / pending-beacon

A better beaconing API

Other

43 stars 8 forks source link

Update API spec in explainer to match latest discussion #16

Closed mingyc closed 2 years ago

mingyc commented 2 years ago

Fix #13:
- Replace pageHideTimeout with backgroundTimeout and timeout.
- Allow to set them in constructor & sub-class's setData() or setURL().
Fix #11: Rename isPending to pending and specify its behaviors.
Address #9: Keep the low-level sync API, and mark it as chosen.
Fix #6:
- Add PendingGETBeacon which supports setURL(url, options).
- Add PendingPOSTBeacon which supports setData(data, options).
- Remove setData(data) from base PendingBeacon.

mingyc commented 2 years ago

cc @philipwalton @fergald PTAL. Please also suggest better naming than PendingGETBeacon, PendingPOSTBeacon, thanks!

fergald commented 1 year ago

I think in the case of

Tab A: top level is userfoo.blog.com, frame is map.company.com Tab B: top level is map.company.com

I think Tab A's map.company.com beacons should still be delivered because

that frame can't create new beacons, the data was put into the beacons before it entered BFCache, it could have sent them immediately, wasting radio, quota, CPU etc, instead it used a beacon with a delay to try save resources in the case that comes back out quickly. Or to put it another way, there is no user expectation being violated about what data is sent.
It's hard to argue that the user has any expectation about when the data is sent since beacon is write-only but since map.company.com is open in another tab, having connections occur to its servers does not seem to violate expectations.

In general I would really like to not impose restrictions on beacon that are not present already because all that does is keep devs doing things the hard way which also tends to be wasteful of user resources.