On Mon, 8 May 2023 at 17:51, Rick Byers <rby...@chromium.org> wrote: > Hi Fergal, > It's exciting to see this moving forward! Just to clarify, this is > effectively an I2S for the unload permissions-policy, is that right? Or are > you also requesting permission to stop firing unload events now too? The > latter is going to require some significant compat analysis, but could be > greatly informed by the experience of having some top-level sites opt-out > of unload for their frame tree. >
Thanks. We're not requesting permission to stop firing at this point. It is the far-away end-point. > > Any plan to trigger a deprecation warning / report for the installation of > unload handlers? It might be tricky to find a good balance of useful > warnings without being too spammy. > Permission policy will do this as is with a console warning and Reporting-API if you attempt to install a handler that is disallowed by policy. > > A couple more questions / comments inline: > > On Mon, May 8, 2023 at 7:43 AM Fergal Daly <fer...@chromium.org> wrote: > >> Contact emails >> >> fer...@chromium.org, kenjibah...@chromium.org >> >> Explainer >> >> >> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md >> >> Specification >> >> https://github.com/whatwg/html/pull/7915 >> > > This is still marked as draft. Can you get this ready for review? If it's > blocked only on having a 2nd implementor show support, then I'd be fine > shipping based on a PR. But we should at least do what we can to solicit > feedback on the spec change prior to shipping. > Yes. There's nothing in the spec change that isn't in the requests for positions but since neither of those are supportive yet, I have not asked for review of the PR. I'm hopeful that once we have data on use on unload in subframe navigations as discussed here <https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320> that Mozilla will be supportive. Those metrics are in 113 but based on the data from beta, we need to change how we record them. > Summary >> >> A Permission-Policy for creating unload event listeners will be added. >> >> Initially, the default policy will be set to allow. From there, Chrome >> will gradually migrate the default policy to deny (i.e. increasingly >> disallow the creation of unload event listeners, eventually reaching a >> state where deny fully becomes the default policy). The ultimate goal is >> to remove support for unload event. >> >> Blink component >> >> Blink>PermissionsAPI >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> >> >> Motivation >> >> The unload event is extremely unreliable. It is ignored in most cases by >> all mobile browsers except Firefox on Android. Furthermore, in Safari, the >> unload event is ignored on both desktop & mobile platforms. >> >> In the current state, unload is a major BFCache blocker (~18 percentage >> points reduction of hit rate for Chrome). >> >> The change will unlock a large fraction of that hit-rate while providing >> an opt-out for those who need more time to migrate. It also sends a clear >> signal that unload should not be used in new development. >> >> Sidenote: the spec was changed to say that unload should only run if the >> page cannot enter BFCache, which reflects Safari’s behavior, However >> neither Chrome nor Mozilla have implemented this behavior. In Chrome's >> case, we believe that this would suddenly break various sites and would >> make it hard for developers to know if/when unload may run. >> >> >> Initial public proposal >> >> None >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/738 >> >> TAG review status >> >> Pending >> >> Risks >> >> Interoperability and Compatibility >> >> If no other browsers implement this, there is a risk that devs continue >> to use unload widely and pages malfunction on chrome. However given that >> alternatives to unload exist it seems entirely possible for sites that are >> actively maintained to move off unload. >> >> Gecko: ( >> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320) >> It's possible that pages are depending on `unload` handlers in subframes >> for functionality even without any main frame navigation. We should try to >> understand how common this is before breaking it. It should be possible to >> measure how often subframe unloads fire when the mainframe is not >> navigating. This will give us an upper bound on the size of the problem, - >> Chrome: we have landed code to measure the occurrence of unload in >> different scenarios. We will report back the findings. >> >> WebKit: https://github.com/WebKit/standards-positions/issues/127 >> > > From a quick skim, it sounds like WebKit is already happy with their > tradeoff of not firing unload and doesn't see a need for an API that > reduces unload further, is that about right? WebKit has mostly shipped > heuristics here without trying to spec them first, right? In general I'm > not too concerned > Yes, there's no great upside for them. I believe the situation as specced where unload is unpredictable and likely biased is bad for devs and is probably skewing data collected via WebKit (and Chrome/Mozilla mobile) but nobody is complaining. I believe there was support expressed offline for the prospect of killing off unload. > > Web developers: Positive ( >> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ) >> The web communities we reached out had positive reactions to our proposal >> and we have not heard about any concrete blockers. >> >> Other signals: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> On WebView, we will introduce the Permissions-Policy but not move the >> default to "deny". BFCache does not work on WebView, so the benefit is >> lower. Meanwhile the risk seems higher as we have far less visibility into >> the HTML being run in WebViews. A roll-out to WebView should be done >> independently and in consultation with the WebView team. >> > > Sounds like the right strategy to me, thanks! > > >> Debuggability >> >> None >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> Flag name >> >> None >> > > Please put the new policy behind a RuntimeEnabledFeature > <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>. > It's effectively a new API so is required > <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> > to have a finch killswitch. It sounds to me like it should be unlikely that > simply adding the new policy could break things, but maybe some scenario is > possible where we decide breakage in 3p iframes is bad enough to warrant an > emergency fix? > Yes, there will be a flag, maybe more than one. The implementation details of rolling this out gradually have not been worked out. See below. > >> Requires code in //chrome? >> >> False >> >> Estimated milestones >> >> M115 for availability of Permissions-Policy >> >> M115 is the earliest we would start to disable unload, however >> > > Is this a typo? Or are you considering disabling the event in the same > release we first make the permissions policy available? > The plan is to make the PP available with a default of enabled and then gradually flip the default to disabled. The details are here <https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#logistics-of-deprecation>. It's not particularly nice. We have the option to just stop 100% but that seems fairly disruptive, F > > Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5579556305502208 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLn_xJP%3D_t4hbEScUNcvF8ZzT3SYUf%3DWJGxCbV1Y4VLsHw%40mail.gmail.com.
