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?
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 <bhee...@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 <bhee...@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 <bhee...@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/CAFKd2qUZra3uuUEtPz5OC%2BogzuFcJ4qPMt7iFmqGJGMj4XrqJg%40mail.gmail.com.
