Hi Rick, Some extra details in case it helps:
- Enterprise/Edu environments: the default behavior will be controllable via a dedicated group policy (i.e. admins will have the option to opt-out), and we have drafted a heads-up in the next Chrome for Enterprise release notes. - Killswitch wise, the default behavior will be controlled via finch flag(s). On Mon, May 8, 2023 at 11:31 PM Rick Byers <rby...@chromium.org> wrote: > 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> >>> . >>> >> -- Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) Product Manager - Chrome Google Japan -- 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/CADWWn7UpQhm7W4v19pnxTTFb-sbCYArnus0z0RWJoWFNMab-4w%40mail.gmail.com.
