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.
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. 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. 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 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? > 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? 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/CAFUtAY_vHhq5wGkTxV48p4-Tf50VWBK7-yhyqdm8T7Uyg7k--w%40mail.gmail.com.
