Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the proposal doesn't consider using Page Lifecycle API #32

Closed
smaug---- opened this issue Sep 13, 2022 · 5 comments
Closed

the proposal doesn't consider using Page Lifecycle API #32

smaug---- opened this issue Sep 13, 2022 · 5 comments

Comments

@smaug----
Copy link

Page Lifecycle API, isn't a proper spec yet, but it is trying to solve some of the issues https://github.com/WICG/unload-beacon/blob/main/README.md#problem-and-motivation talks about. Is there a reason why existing sendBeacon couldn't be used when freeze or visibilitychange event fires?

@fergald
Copy link
Collaborator

fergald commented Sep 13, 2022

I might be misunderstanding what you mean but it sounds like you're suggesting pages would use sendBeacon in some event handlers and PendingBeacon to handle the cases where no event handlers are called? Is that correct?

@smaug----
Copy link
Author

I'm wondering about the motivation section, since it talks about some same issues which Page Lifecycle API was designed to solve. So if one would use freeze event, not unload or beforeunload, or not even pagehide, wouldn't that solve some of the issues we have today. And visibilitychange event could be use for some background tab issues. In other words, which cases are left if those events were used.

@fergald
Copy link
Collaborator

fergald commented Sep 13, 2022

I'm assuming you're talking about using events plus existing network APIs like fetch with keepalive or sendBeacon.

Some of the goals of PendingBeacon are

  • reduce traffic by allowing data to accumulate/integrate within time limits
  • definitely send (with some caveats)
  • timely send (let authors tell us what the time limits are)

JS is paused in BFCache and sometimes when backgrounded and may never be unpaused before the page is discarded. So the only way to achieve "definitely send" is to eagerly send when an event occurs that might result in paused JS. That conflicts with allowing data to accumulate within time limits. We don't want pages sending on every visibility event just in case it might be their last chance to send.

Also, no combination of events+sendBeacon can provide the ability to send after a crash or other sudden termination (common on Mobile), so authors who want that will put their data in a beacon.

@mingyc
Copy link
Collaborator

mingyc commented Sep 14, 2022

if one would use freeze event, not unload or beforeunload, or not even pagehide, wouldn't that solve some of the issues we have today

There were some discussions around which lifecycle event we should support in this thread #13 (comment) and the API ends up switching from supporting pagehide to hidden.

@mingyc
Copy link
Collaborator

mingyc commented Oct 28, 2022

Later discussion in #52 (comment) adds more valuable points why we want a dedicated API that bundles these capabilities together.

I'll close this bug for now. Feel free to re-open with any other concerns.

@mingyc mingyc closed this as completed Oct 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants