Making unload opt-in via Permissions Policy

[fergald]

WebKittens

@annevk @marcoscaceres

Title of the spec

Disable unload handlers by default and add Permissions-Policy to opt-in to enabling them.

URL to the spec

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md

URL to the spec's repository

https://github.com/fergald/docs/

Issue Tracker URL

No response

Explainer URL

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md

TAG Design Review URL

w3ctag/design-reviews#738

Mozilla standards-positions issue URL

mozilla/standards-positions#691

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This is a revised approach to #127

[annevk]

Hey @fergald, thanks for filing a new issue.

Curious, where does the 95% come from?

Overall, removing unload doesn't seem bad per se, but this seems to be again (referring to #127 here; aside: should that be closed?) about standardizing a new feature to account for Chromium's non-compliant behavior with an existing feature. And the behavior of that existing feature in the standard (and WebKit) matches what Chromium engineers suggested a couple years prior. That doesn't make a whole lot of sense to me. Wouldn't a Reverse Origin Trial be more appropriate for cases like this?

[fergald]

@annevk, 95% comes from @nicjansma's report. Firefox is similar. Chrome mobile, and all safari are down in the 50s and 60s. Mobile will be due to a mix of skipping unload for BFCache and mobile's inherent skipping of unload due to kills. Oddly safari mobile is higher than non-mobile

Chrome engineers made the change to the spec. It was considered reasonable at the time (and for mobile it is reasonable because unload is already reliable there) but we've had second thoughts, while tackling desktop. It is a breaking change to move from unload being 95% reliable to 60% reliable. We experimented with it previously and it broke SAS's web app (I might have the wrong company, I can find the details if you really want).

The current unload specced behaviour is not good for devs/sites. It's a compromise that increases BFCache hit-rate by making unload a footgun on desktop when previously it was not. The reasons why it's a footgun are collected here.

We see 2 options (I'm happy to consider any others), both of which are breaking changes

1. leave unload specced as is and have FF and Chrome Desktop come into line with it gradually
2. push sites away from unload but leave it in their control to opt in to the footgun

1 is considerably easier than 2 but 2 leaves the web platform in a better place. If we choose 1, unload will continue to be used by people who don't understand it, injecting bias into stats or occasionally blowing up when a site makes itself BFCacheable and suddenly loses 40% of its unload handlers.

Re: reverse origin trial. If we did an ROT of removing unload, then that would imply that we intend to fully remove unload at the end. We do not have a timeframe in which we intend to remove unload. While it's always possible to switch to pagehide it does need some thought to do so. Some apps are still in user but effectively unmaintained. An ROT would be a much more committed approach. I don't think it's an attractive option. Would WebKit support the full removal of unload at the end of a Chrome ROT?

[annevk]

Would WebKit support the full removal of unload at the end of a Chrome ROT?

Yes.

[fergald]

It's impossible for us to run a reverse origin trial for a feature that is used on maybe 30% of pageloads (I don't know the true fraction of all pageloads but over 30% of potentially cacheable navigations are blocked by this). Also, disabling is known to break installed enterprise software.

If we can reduce that fraction significantly then an ROT may be feasible eventually.

[annevk]

I don't understand. It seems that would apply to the approach outlined in OP as well.

[othermaciej]

Getting 30% of pages to do a new Permissions Policy opt-in only to still block b/f cache in Chrome seems like a waste of everyone's time, unless the theory is that only a very small fraction of 30% really need unload to function and the others just wouldn't do anything, in which case it seems a reverse origin trial would work just as well. What's the hypothetical world where the disruption of Permissions Policy opt-in is ok, but the disruption of ROT is not?

[fergald]

Neither approach can flipped to 100%, they both have to be rolled out to a gradually increasing fraction of users.

The Permissions-Policy approach

• leaves sites able to set the policy they want, either disabled or enabled and have that apply to 100% of users regardless of our rollout
• allows fine-grained control so that sites can keep other unload usages from creeping in while they leaving some enabled allowing
• allows us to provide an enterprise policy so that companies that manage fleets of chrome installs can bulk opt back in if they have an enterprise web app that breaks without unload

ROT:

• commits us to disabling unload fully at some point, we have no idea when this would be
• does not provide any way for sites to get ahead of the game
• requires regular renewal of the origin trial token to keep the status quo
• unclear how we manage enterprises that need to keep unload

ROT is an option but I see no upside for users, sites or anyone who implements it.

[annevk]

It seems that analysis is ignoring a couple aspects, such as Chromium's current implementation not being compliant. At least, I assume the implicit ask is that with the Permissions Policy approach other browsers would adopt Chromium's handling of the unload event? I don't think that works for us.