Hi Kenji, Will there be a way to detect whether or not unload will fire from JS?
We (Akamai) have some security products that may hook into unload, *only* if they detect that *another* script has hooked into unload. When this happens, we also shift some "cleanup" work to that unload handler that we need to execute. Otherwise the cleanup work executes in beforeunload/pagehide/etc. If we have knowledge that unload *won't* execute, we would skip hooking unload and keep our cleanup behavior earlier. (we don't hook unload for any other reason). For browsers that don't reliably execute unload today (e.g. Safari), we a combination of UA sniffing and feature detection. But that could be tricky if Chrome transitions from reliably firing it to not over time. On Friday, April 7, 2023 at 5:03:45 AM UTC-4 Kenji Baheux wrote: > In light of this feedback, we are landing a metric to understand how often > subframe unload handlers run without main frame navigation. > We'll use the data to adjust our plans accordingly. > > Since it takes time to get & analyze the data, *we are pushing the > proposed behavior change to M115*. > > *Adjustments based on feedback received thus far* > We'll offer a "deprecation flag" (a flag to temporarily keep unload > working as it currently does) which should be more convenient than the > Extension suggestion (e.g. unmanaged devices where group policy can't be > deployed). > > We are also removing the following aspect "This policy will also be > enabled by default if Chrome detects that it is in an enterprise / > education environment, as hinted by the presence of one or more existing > group policies." from the proposal since we got feedback that it's better > to keep group policy free of any automated logic. > > I've reached out to a few more communities and have only heard supportive > comments so far (touching wood). > Please continue to help us get the word out so that we can further > minimize the risk of oversights. > Thanks! > > On Thursday, March 30, 2023 at 3:23:16 PM UTC+9 Fergal Daly wrote: > >> [+sm...@mozilla.com] >> >> I'm relaying a piece of feedback from Mozilla in this github issue >> <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. E.g a page >> creates a subframe with an unload handler, when the subframe is destroyed >> or navigates to somewhere else, that unload handler does something >> interesting, e.g. notifies the outer frame that this has happened. >> >> This is definitely possible. It's also pretty easy to switch to pagehide >> for this case but 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, >> >> F >> >> >> On Fri, 24 Mar 2023 at 10:16, Kenji Baheux <kenji...@chromium.org> wrote: >> >>> Tl;dr: the presence of unload event listeners is a primary blocker for >>> back/forward cache on Chromium based browsers and for Firefox on desktop >>> platforms. On the other hand, for mobile platforms, almost all browsers >>> prioritize the bfcache by not firing unload events in most cases. To >>> improve the situation, we’ve been working with lots of partners and >>> successfully reduced the use of unload event listeners over the last >>> few years. To further accelerate this migration, we propose to have Chrome >>> for desktop gradually skip unload events. If this call for feedback >>> doesn’t unearth critical showstoppers and if the proposal makes it through >>> the blink process, the behavior change could be starting from M114 at the >>> earliest (note: beforeunload will remain unchanged). We’d like feedback >>> on this plan, in particular use cases that don’t yet have a viable >>> alternative. >>> >>> >>> >>> Hi, >>> >>> >>> This is a call for feedback about a tentative plan regarding unload >>> events. Our goal is to identify use cases for which there isn’t any good >>> alternative to unload events, and would therefore prevent this plan >>> from moving forward. >>> >>> >>> The unload event is extremely unreliable. It is ignored in most cases >>> by all mobile browsers with the exception of Firefox on Android. >>> Furthermore, in Safari, the unload event is ignored on both desktop & >>> mobile platforms. In addition to being unreliable, the presence of >>> unload event listeners on a page is a major back/forward cache blocker >>> on desktop for Chromium browsers and Firefox. Based on Chrome stats, we >>> believe that unload event listeners reduce bfcache’s ability to deliver >>> instant back/forward navigation by ~18 percentage points (hit-rate). >>> >>> >>> Over the course of 2021~2022, we ran a large collaborative effort to >>> reduce the usage of unload event listeners, in particular across >>> popular third parties. We’ve seen great progress with many sites and third >>> parties having already completed their migration. >>> >>> >>> Given how unreliable unload events are, the potential user experience >>> upsides, and the great progress achieved by the ecosystem on switching away >>> from unload, we’d like to help accelerate the migration by gradually >>> skipping unload events on Chrome for desktop. >>> >>> >>> 👉 Please note that beforeunload will remain unchanged as this event >>> doesn’t have reliability issues and doesn’t block BFCache. 👈 >>> >>> >>> We are interested in hearing your feedback about this plan. In >>> particular, please let us know if you are aware of unload event >>> listener use cases that lack a viable alternative. Your feedback will >>> inform the proposal (e.g. behavior and timeline). >>> >>> >>> If this call for feedback doesn’t unearth any critical showstoppers, and >>> if the proposal makes it through the blink process, we’d start the plan >>> from M114 at the earliest by having a small likelihood of ignoring unload >>> events while providing access to fine-tuning control (e.g. >>> Permission-Policy: >>> unload API <https://chromestatus.com/feature/5760325231050752>) and >>> Enterprise/Edu carve outs. From there, we’ll continue to monitor the >>> community’s feedback and gradually increase the likelihood over time. We >>> are hoping to make significant progress by the end of this year, and hope >>> to reach a satisfying state sometime in 2024. >>> >>> >>> See the sections below for more context, our guidance for a post-unload >>> web, an API to exert control over unload event listeners, and our >>> approach to ease-in enterprise/edu products into this change. >>> >>> >>> >>> Background about bfcache >>> >>> Back/forward cache <https://web.dev/bfcache/> is a browser optimization >>> that enables instant back and forward navigation. It’s an in-memory cache >>> that stores a complete snapshot of a page (including the JavaScript heap) >>> as the user is navigating away. With the entire page in memory, the browser >>> can quickly and easily restore it >>> <https://www.youtube.com/watch?v=cuPsdRckkF0> if the user decides to >>> return. >>> >>> >>> The multiple behaviors of bfcache with unload events >>> >>> Unfortunately, not all pages can be stored in bfcache. For instance, >>> using certain APIs prevent pages from entering the bfcache. In particular, >>> the presence of unload listeners on a page is the most common bfcache >>> blocker. >>> >>> >>> The use of unload listeners is highly discouraged because it’s a >>> fundamentally unreliable event: >>> >>> - >>> >>> On desktop, Chrome and Firefox are currently firing unload events at >>> the cost of the user experience, while Safari will attempt to cache some >>> pages with an unload event listener (skipping the event in doing so). >>> - >>> >>> On mobile, Chrome and Safari will attempt to cache pages with an >>> unload event listener. On the other hand, Firefox treats pages that >>> use unload event listeners as ineligible for the bfcache, except on >>> iOS, which requires all browsers to use the WebKit rendering engine >>> (i.e. >>> all browsers inherently behave like Safari on this platform). >>> >>> >>> Alternatives to unload event listener >>> >>> The recommended alternatives to unload event listeners are to: >>> >>> - >>> >>> Use the pagehide event listener >>> >>> <https://web.dev/bfcache/#only-add-beforeunload-listeners-conditionally:~:text=Instead%20of%20using%20the%20unload%20event%2C%20use%20the%20pagehide%20event.%20The%20pagehide%20event%20fires%20in%20all%20cases%20where%20the%20unload%20event%20currently%20fires%2C%20and%20it%20also%20fires%20when%20a%20page%20is%20put%20in%20the%20bfcache.> >>> >>> (note: despite the name, this serves a different purpose than the page >>> visibility API). >>> - >>> >>> For the cases where user interaction would be useful, conditionally >>> use the beforeunload event listener >>> <https://web.dev/bfcache/#only-add-beforeunload-listeners-conditionally> >>> . >>> - >>> >>> Use sendBeacon >>> <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon> >>> or fetch keepalive >>> >>> <https://developer.mozilla.org/en-US/docs/Web/API/fetch#:~:text=keepalive,Navigator.sendBeacon()%20API.> >>> >>> to send analytics data. >>> >>> >>> In addition, you may be interested in the origin trial >>> <https://developer.chrome.com/origintrials/#/view_trial/1581889369113886721> >>> >>> for the Pending Beacon API >>> <https://chromestatus.com/feature/5690553554436096>. This >>> bfcache-friendly API allows sending a bundle of data to a backend server, >>> ideally at the ‘end’ of a user’s visit to a page. From our observations, we >>> believe this is the most common use case for unload event listeners. >>> Compared to the methods highlighted above, this API has better ergonomics. >>> >>> >>> Test driving a web free of unload event listeners! >>> >>> To understand how the plan might play out, please consider joining the >>> origin >>> trial >>> <https://developer.chrome.com/origintrials/#/view_trial/1012184016251518977> >>> >>> for the Permissions-Policy: unload API >>> <https://chromestatus.com/feature/5760325231050752>. This API allows >>> any site to: >>> >>> - >>> >>> Exert control over unload event listeners (e.g. completely disallow >>> them, or selectively allow them for specific origins). >>> - >>> >>> Report the use of unload event listeners to an endpoint for >>> assessment purposes. >>> >>> >>> Chrome for Enterprise & Education >>> >>> We also acknowledge that providers of enterprise & education solutions >>> may not always have the flexibility to quickly update existing deployments. >>> To minimize concerns, we’ll offer a group policy to keep the current >>> behavior for unload events. This policy will also be enabled by default >>> if Chrome detects that it is in an enterprise / education environment, as >>> hinted by the presence of one or more existing group policies. For >>> unmanaged Enterprise/Edu environments, a simple Chrome extension could >>> inject the relevant calls to the Permission-Policy:unload API for >>> temporarily opting-out the relevant origin(s). >>> >> -- 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/634aa73d-d470-47bd-9659-b0a77cbc6b34n%40chromium.org.
