add lots about why this is ok

[fergald]

@domenic I've tried to summarize our arguments for why blocking unload is OK. I have not managed to get a good wording for the conclusion.

[domenic]

This is a bit vague and I'm unclear how I would read it as another browser vendor... Are there specific APIs other browsers should be sure to ship before shipping this one? (That seems unfortunate if so.)

[fergald]

The beacon API, mentioned at the top could be a prerequisite. That said, even the people who proposed the beacon API were able to move to pagehide (they had concerns but it turned out to be doable). We know that metrics providers, ads and maybe others use unload in the same way.

I've rephrased this to say that there are no known blockers but there are some ergonomics issues.

[fergald]

Actually, I've removed this section and added some more comments on the beacon API.

[domenic]

I might either rephrase this, or add an additional sentence, along the lines of "This means that unload handlers are already not a guaranteed capability that subframes can depend on, and placing some control over this nondeterminism with the parent frame does not make the problem worse".

[fergald]

done.

[domenic]

I think a third major argument is about setting a new default/treating unload as a powerful non-default capability. Something like:

• This is a path toward eventually flipping the default so that unload handlers are only possible if the top frame explicitly grants subframes the ability to use them. That is, making unload handlers similar to other user- or page-disruptive features like geolocation, autoplay, cross-origin-isolated, or document-domain.
• For now, and for the forseeable future, we plan to keep unload handlers available by default. But letting pages enforce this on themselves and their subframes to protect user experience is valuable in the meantime.

It might be worth looking at previous discussions for document-domain and cross-origin-isolated (which feel rather similar): whatwg/html#4170 w3c/webappsec-permissions-policy#241 whatwg/html#5435

[fergald]

I thought about this but then didn't try to express it. When I started thinking about this, it led me down the path of

• 1 switch to flip the default, so that unload handlers don't run
• another switch to re-enable them and we make it very explicit so that it's easy to report on, e.g. make it a header, so you don't have to analyse the page's JS.

I think that is a gentler path but also more complex. I had some idea that it would look like, Permissions-Policy: unload-default() and then a subframe does Permissions-Policy: unload(self) to flip it back on. There are problems there though because if the main frame also does Permissions-Policy: unload() then the subframe cannot undo that. It doesn't fit in the existing PP framework (I think). Maybe reenabling it is a DP not a PP?

I didn't include it because I'd prefer the simpler path if we can get it. If you think the double switch path is the right one then I can make a larger update.

[domenic]

I think we generally do these things by spreading out the switches over time instead of over multiple configuration points. I.e.:

• Time 0: everyone has access to the powerful feature always
• Time 1: everyone has access to the powerful feature by default; parent frames can disallow child frames. (In Permissions Policy terms, this is default allowlist of "*". This is where sync-xhr is.)
• Time 2: only parent frames have access to the powerful feature by default; they can delegate to children using allow="". (In Permissions Policy terms, this is default allowlist of "self". This is where most powerful features that are not on a deprecation path end up.)
• Time 3: nobody has access to the powerful feature by default, but parent frames can opt-in using the Permissions Policy header and if they do so they can delegate to child frames using allow="".
• Time 4: nobody has access to the powerful feature ever

[fergald]

OK, what I was proposing was a step in between 0 and 1 where subframes could rescue themselves even if the parent disagrees. I will not suggest that but I will update it to suggest that 4 is where we want to end up (we are not strongly aiming for that but if unload remains a problem we would consider it).

[fergald]

What I did here is point out that sync-xhr and document-domain almost certainly caused code not to run too and that worked out OK. If you make a stronger case, I'll happily include it. In particular if there are evils of unload that really extend beyond BFCache that I've missed.

[domenic]

Add something affirmative about how this trades off against allowing well-behaved outer frames to protect the user against bad experiences (e.g. slow-to-unload pages and broken bfcache), and how on balance we believe the small risks here are outweighed by the potential upside.

[fergald]

Unfortunately anything that's slow to unload can just be slow to pagehide, they happen at the same timing and block the same things (in chrome at least). So I think bfcache is the win we can claim.

I've updated this.

[domenic]

LGTM