Hey folks, Salesforce hasn't had a chance to do a full scan yet but we can almost guarantee we'll have this somewhere. We do have two questions that we'd like answered:
1. Are you also removing the beforeunload event? 2. Will sendBeacon still work when navigating to another page? Thanks, Greg On Tuesday, July 18, 2023 at 10:31:13 AM UTC-7 rby...@chromium.org wrote: > [Just back from vacation, sorry for the delay] > > On Tue, Jul 11, 2023 at 3:44 AM Robert Knight <robert...@gmail.com> wrote: > >> Hello, >> >> Hypothesis (https://web.hypothes.is, a web page/PDF/ebook annotation >> tool) uses the "unload" event to signal to one end of a message channel >> when the other end is in a frame that is about to go away. This is a >> workaround for the lack of a "close" event in the Channel Messaging API ( >> https://github.com/whatwg/html/issues/1766). If unload events are going >> to be removed from the web platform, it would be useful to have a proper >> solution for detecting when a MessagePort becomes disconnected >> ("disentangled"). >> > > Thank you for sharing! As a general principle > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>, > > we "avoid breaking any use cases which cannot be shown to have a reasonable > alternate implementation". Fergal / Kenji can you follow up offline on this > use case and circle back here with your conclusions? Robert, in your case > could you use the permission policy to re-enable unload events on the frame > until we come up with a better fix? Or are there scenarios where you lack > the ability to add "allow=" attributes to the iframe elements? > > Kind Regards, >> Robert Knight >> >> On Monday, 10 July 2023 at 08:13:49 UTC+1 Yoav Weiss wrote: >> >> Thanks for chiming in, Brandon! >> >> I'm glad to hear that the Enterprise constituency is comfortable with the >> plan. >> I'm concerned that there may be a couple other constituencies that may >> not be: >> >> - Third party widgets that currently use unload to send a single "end >> of page" beacon. fetchLater() <https://github.com/WICG/pending-beacon> is >> aiming to be that replacement, but it's not ready just yet. >> - Enterprise SAAS providers that don't have direct and immediate >> control over their customers' application configuration, nor on their >> users' Enterprise Policy. >> >> I think that a short-lived 3P deprecation trial may address these >> constituencies as well. Would you consider adding that to your plans? >> >> > This makes sense to me. Basically we want a plan where each impacted > constituency can opt-out and where we can analyze the use of those > different opt-out mechanisms, right? I agree a short-lived way for 3Ps to > opt-out is a useful risk-mitigation mechanism, but we will have to > communicate clearly that it's intended only to provide time to adopt a > migration strategy. > >> >> On Sat, Jul 8, 2023 at 12:55 AM 'Brandon Heenan' via blink-dev < >> blin...@chromium.org> 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 >> - >> >> 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. >> >> > Thank you so much Brandon for summarizing your perspective on the > enterprise risk, I agree the mitigations make this seem quite tractable > (though still risky). > > >> >> >> 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+...@chromium.org. >> >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d955dd04-7aac-462a-bd85-d69df8d7d86bn%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d955dd04-7aac-462a-bd85-d69df8d7d86bn%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- 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/7427bcb4-ed55-4eb9-a642-d392fd06015bn%40chromium.org.
