*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/26ee523e-181c-4195-a3cc-e3e0b4705aefn%40chromium.org.
