Re: [w3ctag/design-reviews] early design review: Permissions-Policy: unload (Issue #738)

I'll just add some more context here, `unload` is a bit of a special case. It's a footgun, there is arguably no correct usage of unload. The [recommendation](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) is to never use it. For example, synchronising state in an editor should be done on `visibilitychange` because on mobile, if you are not the foreground tab of of the foreground app, you can be killed at any time to reclaim memory.

Try to think of any usage of `unload`, then consider mobile process killing and also the fact that the [HTML spec says](https://html.spec.whatwg.org/multipage/document-lifecycle.html#unloading-documents) `unload` handlers should only run if the page is not entering BFCache (only WebKit actually implements that on desktop, Chrome and Mozilla block BFCache when they find an `unload` handler, in Chrome's case this is because we believe it's too disruptive to just suddenly stop running `unload` handlers). If you can come up with a legit use of `unload`, please let me know.

Even something like 3rd party iframes beaconing data at the end of page life is questionable because on whether the handler runs depends on whether the embedding page is going into BFCache. This will result in data loss that cannot be compensated for because it's is heavily biased The handler will run 100% of the time on some sites and almost 0% on others. We are developing the [pending beacon API](https://github.com/WICG/pending-beacon) to fill that need

So this permission policy should not be thought of as a way for pages to give selective access to `unload`, it's a way for pages to opt out of `unload` as a footgun of the web platform (similar to syncxhr). There is no perfect way to retract a bad feature but we think that the embedding page should know and care about whether it's safe to disable `unload` and is in a position to push embedded pages to make it safe if it's not already.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/738#issuecomment-1437720313
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/738/1437720313@github.com>