Mukundan, the only rollout plan I've found so far is here: https://developer.chrome.com/docs/web-platform/deprecating-unload#deprecation_timeline
Unfortunately, as an enterprise developer, this timeline doesn't give me much information about when I can expect to see impacts from the deprecation. We've done some work ahead of time to prepare for the deprecation, but it's simply not clear to me when support for the opt-out options themselves will also be dropped. I plan to keep those options enabled for as long as possible because the consequences of this deprecation could be severe for our customers (I work in compliance, so think canceled flights, delayed medical research, etc). We don't control all of the impacted code, so we won't know whether our event wrapper solutions work for everyone until the deprecation hits production. On Thursday, April 9, 2026 at 4:11:22 PM UTC-4 Mukundan Kumar wrote: > Hi, > > Is this event deprecated for all websites or only top 50 websites. Is > there any detailed roll out plan for this? > > On Sunday, May 7, 2023 at 10:43:07 PM UTC-7 Fergal Daly wrote: > >> Contact emails >> >> [email protected], [email protected] >> >> 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 >> <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 >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> 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 >> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e784026-a0ac-414a-b01c-d6eeddca5a06n%40chromium.org.
