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?
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/CAFKd2qX1ADi9Ap0M5ypMThqAySCs%2BF5ARjsdYe0iHzNwzxNRvw%40mail.gmail.com.
