On Thu, 29 Jun 2023 at 14:41, Mike Taylor <miketa...@chromium.org> wrote:
> Hi Fergal, > > Nice to have lunch with you today. > On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev wrote: > > Hi API-owners, > > > I am now asking for permission to go ahead with the following concrete > unload deprecation plan below. > > > > - > > Tools and outreach > - > > M115 Enable `Permission-Policy: unload` (PP:unload) with the > default being enabled. This allows sites to opt-in to unload > deprecation. > - > > Outreach to 1st/3rd parties, to migrate away from using unload and > to enforce this with PP:unload. > - > > Deprecation > - > > M117 change the default for PP:unload so that unload handlers are > skipped by default for 1% of page loads > - > > M118 increase to 5% of page loads > - > > M119 (last of 2023) increase to 10% of page loads > - > > Evaluate progress on reduction of the use of unload > - > > M120-128 increase +10% gradually to 100% of page loads > > > Enterprise policy would allow opt-out entirely. > > > Obviously, the deprecation timeline is contingent on unload usage coming > down in response to the earlier steps. > > Can you spell out a bit more what you're thinking here? I wouldn't expect > much movement when enabled at only 1% (but maybe y'all are super good at > outreach and will prove me wrong) - it's very likely losing 1% of unload > handlers is hard to notice or reproduce (my hunch is that "breakage" here > is subtle, and in the form of missing analytics/pings, etc.). 5% is > probably a big enough dent to notice, maybe? > The earlier steps I am referring to are making `Permissions-Policy: unload` work as a way to disable unload. A large fraction of unload usage comes from a very small number of domains. One of them used PP:unload in Origin Trial and can't wait to use it for real. Having this tool will allow us to bring the number of unloads down considerably. We hope 1% disablement would not be noticed but it's possible it would if we end up breaking things worse than we expect. > I would almost recommend getting to 5% faster than M119 - that's just a > few weeks out from November holidays where many sites go into code freeze > ahead of Black Friday™. > Good point, F > > We expect that 10% of page loads will provide a noticeable signal to sites > that use unload. Also, if we were to just follow the current spec and not > run unload when we can BFCache (as happens on Clank/Firefox mobile and all > WebKit) we expect that we would skip 30-40% of unload handlers when the > main frame navigates. > > Decisions: > > - > > Timeline > - > > All navigations vs main-frame navigations only > > > Standardising > > We have some new data and have had some further discussions with browser > vendors. There's no consensus. TL;DR WebKit are opposed to any > Permissions-Policy but support removing unload eventually. Mozilla are > still discussing. > > Both Mozilla <https://github.com/mozilla/standards-positions/issues/691> > and WebKit <https://github.com/WebKit/standards-positions/issues/127> > were opposed to standardising `Permissions-Policy: unload` (defaulting to > on) because they worried that a containing frame might selectively disable > unload handlers in a child frame for malicious purposes (no specific cases > were discussed). > > So we flipped to the idea of having PP:unload with the default being > disabled. We cannot suddenly do that. We need to roll it out gradually. > WebKit folks are opposed to this and have suggested > <https://github.com/WebKit/standards-positions/issues/200#issuecomment-1596385073> > we do a reverse origin trial instead. If our plan works out, eventually we > would ROT as the final nail but ROT starting now has downsides for users > and sites and no upside for the implementer. > > Mozilla has so far not been negative > <https://github.com/mozilla/standards-positions/issues/691> on the > Permissions-Policy off-by-default approach but they are still discussing. > They are concerned that disabling unloads when subframes are navigating > could be a problem. We found that about 1/4 of subframe navigations involve > an `unload` handler (most seem to involve handlers in cross-site and > same-site site frames). We don't have examples of sites that rely on > `unload` handlers in this way, although they probably do exist. Migrating > to `pageshow` or using PP:unload for these sites should be trivial. > > We have the option to say that PP:unload only applies to main frame > navigations. This would mean these sites would be completely unaffected > however that has some downsides. It is harder to explain and does not end > with full removal of `unload`. We would prefer to have this apply to all > navigations unless we find a good reason not to. If we were to change > part-way, there would be no breakage. We hope that once we drive down usage > in 3rd-part iframes with PP:unload that the number of unload handlers > running in subframe navigations decreases significantly. > > Finally there was some discussion > <https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739> > about how Permissions-Policy off-by-default should work. Our current > version requires every page to set the header and every parent to set the > iframe `allow` attribute. This is maximally conservative. If at some point > later on there is agreement to standardise on something less conservative, > it will not break pages that have already re-enabled `unload`. > > > Overall it seems hard to standardise in advance but if we succeed in > driving down `unload` usage, other browsers are on-board with removing > unload. The worst case scenario would be where we implement PP:unload > (which the others do not agree with) but make no noticeable progress on > `unload` usage. If that happens we can just go with the currently specced > behaviour (don't run `unload` if BFCaching is possible) and maybe revert > the PP:unload, > > F > > On Tue, 9 May 2023 at 16:01, Fergal Daly <fer...@google.com> wrote: > >> 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/CAAozHLnTtwL9jbt0gyS%3DDouUk2yzsHrmgmF7YaDasb-%2B706EOQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLnTtwL9jbt0gyS%3DDouUk2yzsHrmgmF7YaDasb-%2B706EOQ%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/CAAozHLkGx5pY1Y26BLMSP5PxtXaUn_mX3xZbjYc_F%3DXgEgiu5g%40mail.gmail.com.
