-
Notifications
You must be signed in to change notification settings - Fork 69
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
Permission-Policy: unload #691
Comments
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? |
@zcorpan I'm told you are the relevant person. |
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. |
@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. |
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. |
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". |
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. |
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. |
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. |
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. |
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 Do you have an example you are concerned about? |
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). Do you have usage data about unload event listeners in iframes, I mean for cases when top level page is not unloading. |
We don't have that data. We can see about getting it. Thanks. |
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. |
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. |
We have data back from Chrome 114. The denominator is
Numerator is as above AND
Android: 9% 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. |
What do you mean with that? All the subframe navigations fire unload. I guess you mean 25% has unload event listener? |
Yes, it means at least 1 listener. We are considering what to do here. |
Would mozilla support this if the policy only applied during main-frame navigations? |
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? |
Eventually opt-in (i.e.
Everything would still get
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.
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. |
Request for Mozilla Position on an Emerging Web Specification
Other information
w3c/webappsec-permissions-policy#444
The text was updated successfully, but these errors were encountered: