[Just back from vacation, sorry for the delay] On Tue, Jul 11, 2023 at 3:44 AM Robert Knight <robertkni...@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/CAFUtAY970CmvxjY2bF9pvb%3Dwg3E08Lx6uHNxghDAR1gRMFDFXg%40mail.gmail.com.
