Hi Blink API owners, We would like to get approval to start doing a limited experiment on deprecating unload handlers, proposal below. First some updates.
MessagePorts After some investigation, it turns out that Robert Knight (Hypothesis)'s use of `unload` to signal that a MessagePort can be closed can be replaced with `pagehide` since the navigation in question are always in subframes. More generally, signalling like this is not a reliable way to handle this. Use of WeakRefs or combining with WeakRefs will capture all occurrences. The full details are in this explainer <https://github.com/fergald/explainer-messageport-close> which proposes to add an explicit event for this. Firefox have already said <https://github.com/whatwg/html/issues/1766#issuecomment-1708027883> they would implement it. Implementing it isn't a blocker for unload, the explainer documents how to do it with WeakRefs, however it is a nice-to-have. Other use cases Nobody else has raised any problematic use cases. Enterprise We are discussing with enterprise software vendors, how to make the deprecation easier for them, in particular for their on-premises customers. We have added an enterprise policy that allows enterprises to disable the deprecation (leave the default as enabled) for their managed devices. There is also a chrome://flags/deprecated flag for BYOD. We are considering a 3rd-party deprecation-trial. That would likely be ready in M119 (there are some implementation issues that make it non-trivial). The discussions are ongoing. Proposal We would like to go ahead in M118 with the following - deprecate unload (by changing the permissions policy default) for 1% of users on a limited allowlist of hosts. This would be for a limited set of hosts (top N hosts by traffic in UKM for a value of N that may increase as we gather data). This will avoid enterprise vendor instances while still allowing us to get started with the deprecation, F On Thu, 10 Aug 2023 at 20:33, 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/CAAozHLkZO%3DMhhOSqdBqyT47_t0O6eOaA1AmqYD%3Diru7f0sarmw%40mail.gmail.com.
