On Mon, May 8, 2023 at 10:51 AM 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. > > 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 > Whoops, looks like I didn't finish this sentence (a freudian slip perhaps!). What I intended to convey is that given WebKit's state here, I'm not too concerned about getting their support for a permission policy or any particular deprecation path. Chromium almost certainly needs to apply a lot more diligence in how we manage a deprecation path for unload events, especially in enterprise environments where Safari is largely unsupported. 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/CAFUtAY8SDamTuJ-ZSoE%2Bpwh_KUD_n1_uzrqzeY5nkMufzORkLg%40mail.gmail.com.
