On Wed, 25 Oct 2023 at 05:28, Kevin D. <kevin.deyoungs...@gmail.com> wrote:
> Thanks F > > I see origin trial [1] starts soon with 119 and I need clarification: > That origin trial is a little confusing. It ended up not being implemented in 119 and may not even make it into 120. However we not roll this out generally for any version that doesn't have the OT, so hopefully that means you don't need to worry. > > 1. *Does this mean starting Chrome 119, `unload` won't be fired?* > We will experiment with a small fraction of traffic on a restricted set of domains. 119 is the earlier version that supports disabling it but we won't do it in any version that has known issue (e.g. like below). > 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?* > It will also be fixed before any general roll out, but no update yet. > 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?* > Joining the dep trial will cause unload to continue to fire as before, F > > > [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/CAAozHL%3D6YVPiAx610J%2BAQXBdjVhC%3D6Qt7Vj96hU3%2BBH2%2Bm7wbw%40mail.gmail.com.
