Hello blink-dev team, I work for SAP and try to understand how the process of web standards deprecations works in general.
I just posted couple of questions on MDN, illustrated by "unload event" deprecation example. Feedback over this or that channel welcome: https://github.com/orgs/mdn/discussions/438 Many thanks Srdjan, https://github.com/bsrdjan On Friday, August 11, 2023 at 5:42:38 PM UTC+2 Brandon Heenan wrote: > Created crbug/1472321 to track that improvement > > On Fri, Aug 11, 2023 at 1:28 AM Fergal Daly <fer...@google.com> wrote: > >> On Fri, 11 Aug 2023 at 09:08, Brandon Heenan <bhe...@google.com> wrote: >> >>> That makes sense—I suppose a more general wording that would apply here >>> would be "These flags prevent or revert a breaking change and will only be >>> available for a limited time." Does that sound better to you / others on >>> the thread? >>> >> >> That sounds great to me, >> >> F >> >>> >>> On Thu, Aug 10, 2023 at 4:33 AM Fergal Daly <fer...@google.com> wrote: >>> >>>> On Wed, 9 Aug 2023 at 07:23, Brandon Heenan <bhe...@google.com> wrote: >>>> >>>>> Still, previous breaking changes to the unload event that affected SAP >>>>> were present in the /deprecated page, so the safest thing to do is to >>>>> follow the same pattern here, no? >>>>> >>>> >>>> The switch landed here <https://crrev.com/c/4736842>, It's in M117. >>>> I've sent a CL <https://crrev.com/c/4764528> to make it appear on the >>>> deprecated flags page. We can CP that, >>>> >>>> F >>>> >>>> It's not marked as a deprecated feature, so it's just in the regular >>>> flags UI. We can CP a tiny change to move it. What gives me pause is that >>>> the page says >>>> >>>> "These features are disabled by default. They will not be available in >>>> future versions of Chrome." >>>> >>>> This doesn't quite match what we are doing. >>>> >>>> >>>> >>>>> >>>>> On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly <fer...@google.com> wrote: >>>>> >>>>>> On Tue, 8 Aug 2023 at 08:00, Brandon Heenan <bhe...@google.com> >>>>>> wrote: >>>>>> >>>>>>> Flipping the permission policy default is still a breaking change >>>>>>> that requires some action from the developer to keep unload events, >>>>>>> right? >>>>>>> If so, we still want en entry in the /deprecated page so that unmanaged >>>>>>> (vendors/BYOD/outbound) users accessing on-prem deployments have some >>>>>>> mitigation. Kenji and I discussed this case with SAP last week, and >>>>>>> that >>>>>>> level of mitigation seemed necessary. >>>>>>> >>>>>> >>>>>> It's just about naming/presentation - I'm adding a switch no matter >>>>>> what, just whether it shows in the deprecated tab or the main tab, >>>>>> >>>>>> F >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly <fer...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan <bhe...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello, I'm chiming in to provide some thoughts from the enterprise >>>>>>>>> perspective. >>>>>>>>> >>>>>>>>> Our goal is to not block forward progress to the web, but to >>>>>>>>> improve the web in an enterprise-friendly way. You shouldn't ever >>>>>>>>> hear me >>>>>>>>> say "you can't do X because it's scary to the enterprise team." You >>>>>>>>> should >>>>>>>>> instead hear "We expect X to be risky, but here are the things we >>>>>>>>> know we >>>>>>>>> can do to make it much less risky." >>>>>>>>> >>>>>>>>> In this case, yes, this is risky for enterprises. We can say this >>>>>>>>> with confidence because we've seen escalations before when we've made >>>>>>>>> changes to unload events (crbug.com/933153, crbug.com/953228). >>>>>>>>> >>>>>>>>> Kenji and Daisuke have been working with us, and my understanding >>>>>>>>> of the plan is to: >>>>>>>>> >>>>>>>>> - >>>>>>>>> >>>>>>>>> Allow developers to opt-in early to the new behavior (unload >>>>>>>>> event ignored) with a permission policy >>>>>>>>> - >>>>>>>>> >>>>>>>>> Communicate the change on chromestatus and the enterprise >>>>>>>>> release notes (already happening >>>>>>>>> >>>>>>>>> <https://support.google.com/chrome/a/answer/7679408?sjid=15316582819754370342-NA#skpUnload114>). >>>>>>>>> >>>>>>>>> We will provide a bug link for customers for feedback in a future >>>>>>>>> release. >>>>>>>>> - >>>>>>>>> >>>>>>>>> Reach out to enterprises and developers we expect to be >>>>>>>>> affected >>>>>>>>> - >>>>>>>>> >>>>>>>>> Introduce an enterprise policy to allow an IT admin to control >>>>>>>>> unload event behavior >>>>>>>>> - >>>>>>>>> >>>>>>>>> Introduce a flag in chrome://flags/deprecated to allow end >>>>>>>>> users to control unload event behavior >>>>>>>>> >>>>>>>>> >>>>>>>> I looked into this, I'm not sure this should be a deprecated flag. >>>>>>>> It doesn't really fit the description. Some time in the future when we >>>>>>>> start to fully disable unload, there should be a deprecated flag for >>>>>>>> unload >>>>>>>> but right now we are just flipping the permission policy default. >>>>>>>> >>>>>>>> Are you OK with just adding a UI entry for the existing flag that >>>>>>>> controls this Permission-Policy rollout (which is named >>>>>>>> DeprecateUnload but >>>>>>>> I'm happy to rename it) >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> - >>>>>>>>> >>>>>>>>> As early as M117, change the default for the policy so that >>>>>>>>> unload events will be ignored. This is the breaking change, and >>>>>>>>> there's >>>>>>>>> likely to be friction here. The two escalations mentioned above >>>>>>>>> both >>>>>>>>> resulted in respins the first time they reached this point. >>>>>>>>> However, this >>>>>>>>> time around, IT admins will be able to fix their environment >>>>>>>>> immediately >>>>>>>>> with the enterprise policy, end users will be able to fix >>>>>>>>> themselves with >>>>>>>>> the deprecation flag, and developers will be able to fix their app >>>>>>>>> with the >>>>>>>>> permission policy. With those mitigations in place, the risk of >>>>>>>>> requiring a >>>>>>>>> respin (or Finch rollback) due to enterprise impact is >>>>>>>>> dramatically >>>>>>>>> reduced, and this is how we eventually successfully shipped both >>>>>>>>> of those >>>>>>>>> above escalations. >>>>>>>>> - >>>>>>>>> >>>>>>>>> We expect a long transition period after that. By default, the >>>>>>>>> unload event is ignored, but different stakeholders are able to >>>>>>>>> revert to >>>>>>>>> legacy behavior. Within enterprise, we expect the enterprise >>>>>>>>> policy to be >>>>>>>>> the most useful mitigation, and the deprecation flag is the backup >>>>>>>>> for BYOD >>>>>>>>> or unmanaged devices. For the above escalations, this migration >>>>>>>>> period was >>>>>>>>> over a year, and I'm expecting something similar this time. >>>>>>>>> - >>>>>>>>> >>>>>>>>> At some point in the future, we expect to remove those >>>>>>>>> mitigations and remove support for the unload event completely. We >>>>>>>>> don't >>>>>>>>> have any specific dates for that yet; we will be responsive to the >>>>>>>>> needs of >>>>>>>>> web stakeholders, enterprise and otherwise. >>>>>>>>> >>>>>>>>> The two escalations I mentioned above were successfully resolved >>>>>>>>> and the changes to not allow popups on page unload and to not allow >>>>>>>>> synchronous XHRs on page unload were shipped. Both of those changes >>>>>>>>> followed essentially the same plan I just laid out above, and so I >>>>>>>>> think >>>>>>>>> it's reasonable to do the same thing here. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote: >>>>>>>>> >>>>>>>>>> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux <kenji...@google.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly <fer...@google.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Thu, 29 Jun 2023 at 01:16, Rick Byers <rby...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Fergal, >>>>>>>>>>>>> Thanks for pushing through this contentious and challenging >>>>>>>>>>>>> deprecation. We discussed this in the API owners meeting today >>>>>>>>>>>>> and were >>>>>>>>>>>>> worried that this plan seemed likely to be seriously problematic >>>>>>>>>>>>> for >>>>>>>>>>>>> enterprises (policy opt-out is helpful, but far from a silver >>>>>>>>>>>>> bullet >>>>>>>>>>>>> unfortunately). To what extent have you engaged with them and >>>>>>>>>>>>> worked to >>>>>>>>>>>>> follow the enterprise breaking change policy >>>>>>>>>>>>> <https://www.chromium.org/developers/enterprise-changes/>? >>>>>>>>>>>>> Our hunch is that at 1% or 5% we'd get escalations forcing us to >>>>>>>>>>>>> abandon >>>>>>>>>>>>> this plan. Of course, if the enterprise team is OK with it, we >>>>>>>>>>>>> could always >>>>>>>>>>>>> try anyway and see if our hunch is right. It's possible I'm >>>>>>>>>>>>> over-indexing >>>>>>>>>>>>> on past experiences like deprecating sync XHR in unload >>>>>>>>>>>>> handlers >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/LnqwTCiT9Gs/m/tO0IBO4PAwAJ> >>>>>>>>>>>>> >>>>>>>>>>>>> and that the enterprise world is different now, but I doubt it >>>>>>>>>>>>> :-). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In addition to Daisuke's response... are you concerned about >>>>>>>>>>>> enterprises that are not using fleet management and so cannot use >>>>>>>>>>>> the >>>>>>>>>>>> opt-out? If you think an enterprise policy will not be sufficient, >>>>>>>>>>>> a >>>>>>>>>>>> mitigation for those enterprises would be for us to publish an >>>>>>>>>>>> extension >>>>>>>>>>>> that allows anyone to re-enable unload (for all sites or for >>>>>>>>>>>> specific >>>>>>>>>>>> sites) by injecting the PP:unload header. Are the escalations that >>>>>>>>>>>> can't be >>>>>>>>>>>> resolved by either a policy or extension? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> One extra comment on the extension option (great for desktop). >>>>>>>>>>> >>>>>>>>>>> If you wonder about the mobile BYOD scenarios, where extensions >>>>>>>>>>> don't exist, then we are a bit lucky here because unload is already >>>>>>>>>>> unreliable on mobile. So, it seems extremely unlikely that we'd see >>>>>>>>>>> mobile >>>>>>>>>>> enterprise/edu products that rely on unload on mobile. >>>>>>>>>>> >>>>>>>>>>> *Rick:* are there specific scenarios / environments that we >>>>>>>>>>> haven't covered? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm glad to see the conversation with the enterprise team is >>>>>>>>>> further along than I had realized. Having skip unload events in the >>>>>>>>>> release >>>>>>>>>> notes >>>>>>>>>> <https://support.google.com/chrome/a/answer/7679408?sjid=5091298988245423514-NA#skpUnloadEv113> >>>>>>>>>> >>>>>>>>>> since M113 is a significant mitigation, sorry I wasn't caught up on >>>>>>>>>> the >>>>>>>>>> latest. And yes some sort of user opt-out for BYOD (extension or >>>>>>>>>> chrome::/flags, etc.) seems like an essential mitigation. I defer to >>>>>>>>>> the >>>>>>>>>> enterprise team's judgement here, so if they're OK with proceeding >>>>>>>>>> then we >>>>>>>>>> shouldn't let my enterprise fears block us. I expect we do need some >>>>>>>>>> easy >>>>>>>>>> way for an application to signal that it really does need unload >>>>>>>>>> handlers. >>>>>>>>>> Setting a permission policy is likely orders of magnitude easier >>>>>>>>>> than >>>>>>>>>> converting essential unload handlers to pagehide and ensuring >>>>>>>>>> they're safe >>>>>>>>>> to invoke multiple times. >>>>>>>>>> >>>>>>>>>> The other major constituency potentially impacted are ad >>>>>>>>>> networks. Perhaps the next step should be a 1% finch trial where we >>>>>>>>>> can >>>>>>>>>> measure various ad-related metrics? I'd defer to the judgment of the >>>>>>>>>> Chrome >>>>>>>>>> Ads team (@Josh Karlin). >>>>>>>>>> >>>>>>>>>> Anyway, I'm personally OK with 1% stable experiments (and >>>>>>>>>> whatever else on dev/beta). But I think we should discussing >>>>>>>>>> learnings from >>>>>>>>>> such 1% experiments here publicly before approving a plan to go >>>>>>>>>> beyond that. >>>>>>>>>> >>>>>>>>>> In general Yoav and I disagree with the WebKit and Gecko feedback >>>>>>>>>>>>> here and suspect that your original PP default-on proposal is far >>>>>>>>>>>>> more >>>>>>>>>>>>> likely to be a successful deprecation path for Chrome (and, >>>>>>>>>>>>> should they >>>>>>>>>>>>> choose to follow, Edge). I can understand why Firefox and WebKit >>>>>>>>>>>>> don't have >>>>>>>>>>>>> the same constraints around enterprises and so would choose >>>>>>>>>>>>> differently for >>>>>>>>>>>>> themselves. Yoav and I are happy to help in the standards >>>>>>>>>>>>> discussions. I'm >>>>>>>>>>>>> about to go on vacation for 2 weeks but Yoav said he'd follow up >>>>>>>>>>>>> with you >>>>>>>>>>>>> privately to brainstorm next steps. Sound good? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I would love to get moving on PP:unload ASAP no matter what. >>>>>>>>>>>> It's been through OT and is sitting behind a flag with some sites >>>>>>>>>>>> eager to >>>>>>>>>>>> use it. I'm happy to send an I2S for that while we discuss the >>>>>>>>>>>> harder >>>>>>>>>>>> problem. We hope that getting that out there can clear out a large >>>>>>>>>>>> chunk of >>>>>>>>>>>> the 1st- and 3rd-party unload usage, >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1, I'd suggest doing that regardless. >>>>>>>>>>> >>>>>>>>>>> There are a few large sites that have done some legwork on >>>>>>>>>>> unload handlers (theirs and third party partners), and are >>>>>>>>>>> interested in >>>>>>>>>>> pushing the remaining unload handlers out with PP:unload. Having >>>>>>>>>>> allies in >>>>>>>>>>> the ecosystem (i.e. extra incentives to migrate), will be helpful >>>>>>>>>>> going >>>>>>>>>>> forward :) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yep I think this was Yoav and my primary concern. For chrome to >>>>>>>>>> have a pragmatic and reasonable deprecation path given our user >>>>>>>>>> base, we >>>>>>>>>> really need sites adopting such an API. If we're not going to >>>>>>>>>> actually ship >>>>>>>>>> such an API then I think we'd have to give up on deprecating unload. >>>>>>>>>> I'd >>>>>>>>>> support shipping this API despite the lack of support from WebKit >>>>>>>>>> and >>>>>>>>>> Gecko. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> F >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Rick >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jun 28, 2023 at 4:07 AM Fergal Daly <fer...@google.com> >>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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, kenji...@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+...@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/32437ced-5f16-4448-b0d8-ffab8aeb9044n%40chromium.org.
