Thanks F I see origin trial [1] starts soon with 119 and I need clarification:
1. *Does this mean starting Chrome 119, `unload` won't be fired? * 2. The Permissions Policy alternative does not work with sourceless iframes (iframes using `srcdoc`). You filed a bug [2] earlier for that after I raised it, any* updates?* 3. My team is experimenting with `pagehide` as an alternative solution, but would like to know the timelines for us to plan and ship accordingly. *Will `unload` still fire during the dep. trial? * [1] https://developer.chrome.com/origintrials/#/view_trial/4070128163236085761 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1491597 On Tuesday, October 10, 2023 at 6:02:41 PM UTC-7 Kevin D. wrote: > *Does the Permissions-Policy: unload API > <https://chromestatus.com/feature/5760325231050752> not support sourceless > subframes?* (i.e. iframes without *src* attributes and with content set > inline in *srcdoc*) > > My team uses sourceless iframes, and hooks to the *unload* event for > cleaning up resources and such (to avoid potential memory leaks, etc.). > > We’ve tried replicating your demo > <https://dyn.fergaldaly.com/~fergal/html/pp-unload/enabled/> showing how > subframes can still use the unload event with Permissions-Policy even after > the deprecation, but our repro confirms it does not work for sourceless > iframes case. > > *Secondly, does the pagehide event serve as an exact replacement for our > case? *(sourceless iframes needing to clear resources). According to > Back/forward > cache > <https://web.dev/articles/bfcache#only-add-beforeunload-listeners-conditionally:~:text=Instead%20of%20using%20the%20unload%20event,%20use%20the%20pagehide%20event.%20The%20pagehide%20event%20fires%20in%20all%20cases%20where%20the%20unload%20event%20currently%20fires,%20and%20it%20also%20fires%20when%20a%20page%20is%20put%20in%20the%20bfcache.>, > > *pagehide *events should be a superset of *unload*. > > Thanks > Kevin > On Wednesday, March 29, 2023 at 11:23:16 PM UTC-7 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/06e2d8be-21b6-4cc3-bccc-3c8290bcbb09n%40chromium.org.
