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 <bhee...@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 <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/CAFKd2qWpnY6gUATjQAVUks0WfGnpcyMtrzAGB5hT-QULHrem2g%40mail.gmail.com.
