Permission-Policy: unload

[fergald]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Permission-Policy: unload
• Specification or proposal URL: add unload permissions-policy feature whatwg/html#7915
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): Randell Jesup and Olli Pettay have some context on this at least

Other information

w3c/webappsec-permissions-policy#444

[torgo]

Hi 👋🏻 moz folks - we're in the process of a TAG Review on this and one of the factors we consider is multi-implementer support. Is there any information y'all can share?

[fergald]

@zcorpan I'm told you are the relevant person.

[smaug----]

So the proposal would basically let parent document to break iframes. That is worrisome, especially for the cases when iframe navigates itself to some other page.

Looks like w3c/webappsec-permissions-policy#444 (comment) was saying the same thing.

[fergald]

@smaug---- Yes. In practice sites can prevent unload handlers running right now on mobile Firefox/Chrome and mobile+desktop WebKit by ensuring they can be BFCached. So if this is exploitable, it's already a problem.

We can keep living with unload handlers, their negative impact on performance via BFCache blocking and the fact that they may or may not run depending on what browser/OS you're on or we can give devs a way to get away from unload handlers in a controlled fashion.

[smaug----]

I'm talking about the case when top level page is happily up and running (not in bfcache) and iframes navigate to some other pages. That is case when unload listeners are expected to run. Nothing exploitable there.

[fergald]

I hadn't thought about this before but we could change the semantics so that handlers run when the navigation occurs in a subframe that didn't request unload blocking. So e.g. if the top-level requests to block it for all frames it and the top-level navigates then nobody's handlers run but if a subframe navigates and it didn't request unload-blocking then it's unload handlers run.

I don't really like that idea because it makes it even harder to understand when unload handlers will/won't run rather than just making it "never".

[fergald]

The context around this has changed now. We would like to go ahead with this but with a default of preventing unload handlers from running. Details here.

[smaug----]

It is still unclear to me how unload in iframe page loads behave.

And looks like the comment about unload blocking bfcache on mobile Firefox isn't quite right. it should block only on same-origin case - because that used to be the case also in Chrome.

[fergald]

For iframes, if they do not have the permission, unload handlers will not run under any circumstances. While we are motivated by the BFCache benefits I don't see a good reason to handle iframes differently.

Essentially this latest proposal reflects the fact that bringing desktop into line with mobile (skipping unload in favour of BFCache) is not a great end-point (unload is now unreliable everywhere) and getting there from the current state is disruptive. If we're going to cause this disruption, let's target an end-point where unload is a legacy feature that requires opt-in.

I'm open to correction on Firefox's blocking. Chrome's behaviour is that unload in any frame in the page will prevent BFCache on same origin or cross origin.

[smaug----]

ok, so that unload handling for iframes would be something very new. Firefox/Chrome/Safari both on desktop and mobile fire unload for iframe loads.
http://mozilla.pettay.fi/moztests/iframe_parent.html

[fergald]

Mobile Chrome and all Safari will not fire those unloads when navigating away from a page that can be BFCached. I thought mobile Mozilla was the same but I could be wrong.

I don't think it would make sense to keep unload working in some cases and not others when pagehide will work in all cases. Every one of those unloads also fires a pagehide with .persisted==false so I don't believe there's any capability being lost here.

Do you have an example you are concerned about?

[smaug----]

I'm concerned about sites relying on unload event listeners in iframes in cases when the top level page is not being navigated. (So, nothing is entering bfcache in that case).
web-platform-tests seem to rely on unload firing on iframes, at least in some tests, as an example, if I read the tests correctly.

Do you have usage data about unload event listeners in iframes, I mean for cases when top level page is not unloading.

[fergald]

We don't have that data. We can see about getting it. Thanks.

[fergald]

Our proposal has been replaced with one to deprecate unload handlers.

Should I file a new standards request or just continue in this one?

We should have code to measure the subframe navigations use of unload soon.

[smaug----]

I think we can use this same standards-position issue for the new proposal too. But would be indeed good to get data about subframe navigations.

[fergald]

We have data back from Chrome 114. The denominator is

• subframe navigations
• excluding navigation away from initial empty document/about:blank

Numerator is as above AND

• an unload handler would fire for this navigation (in any frame)

Android: 9%
Lacros: 10%
Linux: 15%
MacOS: 27%
WIndows: 24%
ChromeOS: We don't have data yet, the release cycle is quite different

Restricting to unload handlers that are same-origin as the navigating frame reduces the numbers by about 1-2 percentage points.

Being conservative and also adding navigations from initial empty document/about:blank that would fire unload to the numberator (leaving the denominator unchanged since the vast majority of those navigations are not "real" navigations, they typically happen immediately after the frame is created) adds about 1 percentage point.

So in the extreme about 25% of subframe navigations fire an unload.

Also, subframe navigations are about 5% of all navigations on Android and 25% of all navigations on Windows (excluding from about:blank etc). That's a very high fraction of subframe navigations. It's one or two orders of magnitude higher than I consciously experience as a user. I think most of them must be driven automatically, e.g. refreshing ads or something like that.

[smaug----]

So in the extreme about 25% of subframe navigations fire an unload.

What do you mean with that? All the subframe navigations fire unload. I guess you mean 25% has unload event listener?
If so, that is a lot and breaking that by default doesn't sound quite doable.

[fergald]

Yes, it means at least 1 listener. We are considering what to do here.

[fergald]

Would mozilla support this if the policy only applied during main-frame navigations?

[smaug----]

I discussed with @petervanderbeken and we have some questions:

Would it be still opt-out? Or opt-in?

Which events would fire and when? Would iframes get unload when navigation is for an iframe, but when the top level page is about to enter bfcache, unload would not fire? But would they get still pagehide?
And would the permission policy affect whether unload fires on iframes when top level page is navigated?

[fergald]

Would it be still opt-out? Or opt-in?

Eventually opt-in (i.e. unload listeners will not fire unless you opt-in via PP:unload) but flipping to opt-in in one go is too aggressive. So it would have to start opt-out and move to opt-in. You can either consider the whole process (if you think you would go along with it) or just wait and see if Chrome can get unload usage low enough to be able to flip to the end state.

Would iframes get unload when navigation is for an iframe, but when the top level page is about to enter bfcache, unload would not fire? But would they get still pagehide?

Everything would still get pagehide.

unload running or not would not depend on BFCache. Depending on BFCache is the currently specced behaviour and it leaves unload as a footgun.

There's a choice to be made about whether to apply this to all navigations or just top-level. Just top-level leaves us in a confusing state (although still better than current specced behaviour). All navigations would put us on the path to fully removing unload but is likely to break more.

And would the permission policy affect whether unload fires on iframes when top level page is navigated?

Permission policy disabling would impact everything inside that frame. Permission policy that is disabled by default and needs to be enabled is still undecided but at the very least would need to be applied at the top-level frame for any other frame to enable it.