On Fri, 1 May 2026 at 00:00, 'Stephen Schmith' via blink-dev < [email protected]> wrote:
> > 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. > > I can confirm that `onbeforeunload` doesn't fire when we launch older > Articulate Rise SCORM content inside an iframe. I'm not sure why this > happens - it occurs even if the user interacts with the content by clicking > elements inside it. Our internal content team was able to replicate it as > well. These older Articulate content objects add both `onunload` and > `onbeforeunload` event handlers to a body tag, but neither one fires when > I've enabled the `unload` event deprecation. In our case these are > same-origin iframes. > The unload deprecation flag should have no impact on beforeunload, they are completely unrelated events (implementation-wise we don't fire/not-fire the event, we actually prevent you from installing the unload handler and show you a deprecation message). Is there a public URL where I can see beforeunload not firing? F > I'll add that the Articulate content itself also embeds multiple > same-origin iframes, and it's one of these iframes that contains the body > tag with the event handlers mentioned above. And to be clear, this isn't > under control of our developers - the learning content we serve is > developed by third parties. So although we understand how these events > should be used, we can't guarantee that all of our customers have updated > their content objects to newer versions where these unload-related issues > have been fixed. > > > 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. > > Understood - not a new a problem for us on mobile. > > On Thursday, April 30, 2026 at 12:15:03 AM UTC-4 Fergal Daly wrote: > >> 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 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/02cc4afc-17ed-44e4-981f-14c6296eb85dn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02cc4afc-17ed-44e4-981f-14c6296eb85dn%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/CAAozHL%3D4sWEWDnsB5y8d8gefQ7E8RC6kh6zu6mwtyyCQAq2Mtg%40mail.gmail.com.
