Intent to Deprecate: Deprecate unload event

3,964 views
Skip to first unread message

Fergal Daly

unread,
May 8, 2023, 1:43:07 AM5/8/23
to blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland

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


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


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


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.



Debuggability

None


Is this feature fully tested by web-platform-tests?

Yes


Flag name

None


Requires code in //chrome?

False


Estimated milestones

M115 for availability of Permissions-Policy

M115 is the earliest we would start to disable unload, however


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5579556305502208


Rick Byers

unread,
May 8, 2023, 4:51:24 AM5/8/23
to Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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.

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.

A couple more questions / comments inline:

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.

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


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 

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?

Yes


Flag name

None


Please put the new policy behind a RuntimeEnabledFeature. It's effectively a new API so is 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?
 

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?

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.

Rick Byers

unread,
May 8, 2023, 10:31:13 AM5/8/23
to Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
Whoops, looks like I didn't finish this sentence (a freudian slip perhaps!). What I intended to convey is that given WebKit's state here, I'm not too concerned about getting their support for a permission policy or any particular deprecation path. Chromium almost certainly needs to apply a lot more diligence in how we manage a deprecation path for unload events, especially in enterprise environments where Safari is largely unsupported. 

Kenji Baheux

unread,
May 8, 2023, 10:13:25 PM5/8/23
to Rick Byers, Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
Hi Rick,

Some extra details in case it helps:
  • Enterprise/Edu environments: the default behavior will be controllable via a dedicated group policy (i.e. admins will have the option to opt-out), and we have drafted a heads-up in the next Chrome for Enterprise release notes.
  • Killswitch wise, the default behavior will be controlled via finch flag(s).

--
Kenji BAHEUX (my how-to)
Product Manager - Chrome
Google Japan

Fergal Daly

unread,
May 9, 2023, 3:01:49 AM5/9/23
to Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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:

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 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


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?

Yes


Flag name

None


Please put the new policy behind a RuntimeEnabledFeature. It's effectively a new API so is 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. It's not particularly nice. We have the option to just stop 100% but that seems fairly disruptive,

F

Fergal Daly

unread,
Jun 28, 2023, 4:07:10 AM6/28/23
to Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland

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 and WebKit 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 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 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 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

Rick Byers

unread,
Jun 28, 2023, 12:16:32 PM6/28/23
to Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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? 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 and that the enterprise world is different now, but I doubt it :-).

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?

Rick

Daisuke Enomoto

unread,
Jun 28, 2023, 7:11:13 PM6/28/23
to Rick Byers, Fergal Daly, blink-dev, Kenji Baheux, Ian Clelland
Hi Rick,

Thank you for your review and feedback. On the enterprise engagement, we have informed them about these upcoming planned changes back in March and have continued the engagement with them to ensure enterprise visibility. Specifically, the planned change was mentioned in the enterprise release note for M113M114 and M115 (in draft). This is all on top of the launch process and the group policy availability.

That said, I will double check with them to ensure they have the correct understanding of our plan and get back to this thread.

Daisuke

Fergal Daly

unread,
Jun 29, 2023, 12:48:44 AM6/29/23
to Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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? 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 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?
 

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,

F

Mike Taylor

unread,
Jun 29, 2023, 1:41:24 AM6/29/23
to Fergal Daly, Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland

Hi Fergal,

Nice to have lunch with you today.

On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev 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.

Can you spell out a bit more what you're thinking here? I wouldn't expect much movement when enabled at only 1% (but maybe y'all are super good at outreach and will prove me wrong) - it's very likely losing 1% of unload handlers is hard to notice or reproduce (my hunch is that "breakage" here is subtle, and in the form of missing analytics/pings, etc.). 5% is probably a big enough dent to notice, maybe?

I would almost recommend getting to 5% faster than M119 - that's just a few weeks out from November holidays where many sites go into code freeze ahead of Black Friday™.

Kenji Baheux

unread,
Jun 29, 2023, 1:47:27 AM6/29/23
to Fergal Daly, Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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? 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 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?


 
 

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 :)

Fergal Daly

unread,
Jun 29, 2023, 8:51:30 AM6/29/23
to Mike Taylor, Rick Byers, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
On Thu, 29 Jun 2023 at 14:41, Mike Taylor <mike...@chromium.org> wrote:

Hi Fergal,

Nice to have lunch with you today.

On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev 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.

Can you spell out a bit more what you're thinking here? I wouldn't expect much movement when enabled at only 1% (but maybe y'all are super good at outreach and will prove me wrong) - it's very likely losing 1% of unload handlers is hard to notice or reproduce (my hunch is that "breakage" here is subtle, and in the form of missing analytics/pings, etc.). 5% is probably a big enough dent to notice, maybe?


The earlier steps I am referring to are making `Permissions-Policy: unload` work as a way to disable unload. A large fraction of unload usage comes from a very small number of domains. One of them used PP:unload in Origin Trial and can't wait to use it for real. Having this tool will allow us to bring the number of unloads down considerably.

We hope 1% disablement would not be noticed but it's possible it would if we end up breaking things worse than we expect.

I would almost recommend getting to 5% faster than M119 - that's just a few weeks out from November holidays where many sites go into code freeze ahead of Black Friday™.

Good point,

F

Rick Byers

unread,
Jun 29, 2023, 10:02:06 AM6/29/23
to Kenji Baheux, Josh Karlin, Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland
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? 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 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 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. 

Brandon Heenan

unread,
Jul 7, 2023, 6:55:43 PM7/7/23
to blink-dev, Rick Byers, Fergal Daly, blink-dev, Daisuke Enomoto, Kenji Baheux, Ian Clelland, Josh Karlin

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/933153crbug.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). 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.

Yoav Weiss

unread,
Jul 10, 2023, 3:13:49 AM7/10/23
to Brandon Heenan, blink-dev, Rick Byers, Fergal Daly, Daisuke Enomoto, Kenji Baheux, Ian Clelland, Josh Karlin
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() 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?

Robert Knight

unread,
Jul 11, 2023, 9:56:35 AM7/11/23
to blink-dev, Yoav Weiss, blink-dev, Rick Byers, Fergal Daly, Daisuke Enomoto, Kenji Baheux, Ian Clelland, Josh Karlin, Brandon Heenan
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").

Kind Regards,
Robert Knight

Rick Byers

unread,
Jul 18, 2023, 1:31:13 PM7/18/23
to Robert Knight, blink-dev, Yoav Weiss, Fergal Daly, Daisuke Enomoto, Kenji Baheux, Ian Clelland, Josh Karlin, Brandon Heenan
[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, 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() 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/933153crbug.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). 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). 

Greg Whitworth

unread,
Jul 27, 2023, 11:37:09 AM7/27/23
to blink-dev, rby...@chromium.org, blink-dev, yoav...@chromium.org, Fergal Daly, deno...@google.com, kenji...@google.com, Ian Clelland, Josh Karlin, Brandon Heenan, Robert Knight
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

Rick Byers

unread,
Jul 27, 2023, 1:38:54 PM7/27/23
to Greg Whitworth, blink-dev, yoav...@chromium.org, Fergal Daly, deno...@google.com, kenji...@google.com, Ian Clelland, Josh Karlin, Brandon Heenan, Robert Knight
On Thu, Jul 27, 2023 at 11:37 AM Greg Whitworth <gregcwh...@gmail.com> wrote:
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:

Thanks Greg! I imagine it's going to be quite hard to know where unload handlers are critical vs. unimportant, so perhaps the most important thing is for us to coordinate on the experimentation and opt-out plan. To what extent do you feel comfortable that the opt-out mechanisms the team have described (permissions policy, enterprise policy, and worst case a user setting) will be adequate for you to manage any disruption? 

I'll attempt to answer your questions on behalf of the team since it's night time in Tokyo now. But I'm sure Fergal / Kenji can add more color later.

1. Are you also removing the beforeunload event?

No. We discourage use of beforeunload due to bfcache impact on Firefox, it doesn't prevent bfcache on Chrome.

2. Will sendBeacon still work when navigating to another page?

Yes it should, sendBeacon is one of the features designed to eliminate dependency on the unload event. 

Ian Clelland

unread,
Jul 27, 2023, 3:54:17 PM7/27/23
to Rick Byers, Greg Whitworth, blink-dev, yoav...@chromium.org, Fergal Daly, deno...@google.com, kenji...@google.com, Josh Karlin, Brandon Heenan, Robert Knight
On Thu, Jul 27, 2023 at 1:38 PM Rick Byers <rby...@chromium.org> wrote:
On Thu, Jul 27, 2023 at 11:37 AM Greg Whitworth <gregcwh...@gmail.com> wrote:
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:

Thanks Greg! I imagine it's going to be quite hard to know where unload handlers are critical vs. unimportant, so perhaps the most important thing is for us to coordinate on the experimentation and opt-out plan. To what extent do you feel comfortable that the opt-out mechanisms the team have described (permissions policy, enterprise policy, and worst case a user setting) will be adequate for you to manage any disruption? 

I'll attempt to answer your questions on behalf of the team since it's night time in Tokyo now. But I'm sure Fergal / Kenji can add more color later.

1. Are you also removing the beforeunload event?

No. We discourage use of beforeunload due to bfcache impact on Firefox, it doesn't prevent bfcache on Chrome.

2. Will sendBeacon still work when navigating to another page?

Yes it should, sendBeacon is one of the features designed to eliminate dependency on the unload event. 

Adding to that, a new fetchLater API (originally PendingBeacon) is being developed by the team in parallel to specifically solve the problem of sending beacons on page unload. Rather than relying on an unload event, it will let you register a beacon earlier, to be sent at the point where the user navigates away or closes the page.

Fergal Daly

unread,
Jul 27, 2023, 11:02:01 PM7/27/23