On Wed, 29 Apr 2026 at 06:27, 'Stephen Schmith' via blink-dev < [email protected]> wrote:
> Thanks for the clarifications! That's helpful. > > As for examples, the failure cases I've seen mostly have to do with > learning management systems - specifically SCORM content objects, some of > which rely on the unload and beforeunload events to trigger communication > with LMS server. Neither of these events fires reliably when the content is > unloaded, which is expected, but it's also not something we have direct > control over. However there are multiple ways to deal with this issue and I > don't necessarily expect us to have problems - I just think it's good to be > cautious considering the impact. > When do you see `beforeunload` being unreliable? It should only be used to warn a user that there is unsaved data and it should be reliable for that. There are some anti-abuse rules <https://chromestatus.com/feature/5082396709879808> like if the user has not interacted with the page at all, we will not allow `beforeunload` to block the page. Also if it takes too long to run, I believe we will navigate away anyway. `unload` is definitely unreliable which is why we are trying to push people away from it. Any auto-save data should be saved from `visibilitychange` because on mobile that event is reliable and is the last event you get before going into the background. Once the page or app is no longer foreground, it may be killed by the OS with no notice. F > On Tuesday, April 28, 2026 at 10:40:27 AM UTC-4 Barry Pollard wrote: > >> I've added some additional wording to the doc post >> <https://developer.chrome.com/docs/web-platform/deprecating-unload#control_access_to_unload> >> : >> >> While we would encourage site owners to move away from using unload >>> handlers given their unreliability, we plan to support this opt-out for the >>> considerable future for sites that need to use it. Additionally, opting >>> back in does not make unload handlers any more reliable on mobile—it just >>> restores the current status quo. >> >> >> and similar under the enterprise policy section >> >> Again, we would encourage site owners to stop depending on unload >>> handlers, but Chrome plans to support this enterprise opt-out for the >>> considerable future for sites that need to use it. >> >> >> Hopefully that addresses any immediate concerns. And if you can share any >> concrete examples of breakage that we should be aware of if we do ever come >> to removing those then do let us know! >> >> >> >> On Tue, 28 Apr 2026 at 01:49, 'Fergal Daly' via blink-dev < >> [email protected]> wrote: >> >>> On Mon, 27 Apr 2026 at 23:47, 'Stephen Schmith' via blink-dev < >>> [email protected]> wrote: >>> >>>> 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. >>>> >>> >>> There is currently no plan to disable the opt-out options. I'll make >>> sure the link above says this explicitly, >>> >>> F >>> >>> >>> >>>> >>>> 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 a topic in the >>>> Google Groups "blink-dev" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/dvusqw9-IhI/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e784026-a0ac-414a-b01c-d6eeddca5a06n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "blink-dev" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/dvusqw9-IhI/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> >> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmYDSjwMkUP6Z%3DMEmB4b8RnLEgNY-eu63q3zQMceYrsTA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmYDSjwMkUP6Z%3DMEmB4b8RnLEgNY-eu63q3zQMceYrsTA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/dvusqw9-IhI/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07e1b62e-e336-4a21-9b90-873fa877f77en%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07e1b62e-e336-4a21-9b90-873fa877f77en%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLnOA7JEOX0q7tCFhBGGuyAa6UhcpTVX%3D5Qy_Vcq6t2uzA%40mail.gmail.com.
