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/CAAozHL%3DCyCeG%3D00SZEFr9%2BL3t9Mw5%3DKUp17cRLHkY%2BU-tOFsFg%40mail.gmail.com.
