On Thu, 26 Oct 2023 at 01:11, Kevin D. <kevin.deyoungs...@gmail.com> wrote:
> Understood. > > > 1. *Is there any action required from us until general rollout (when > `unload` isn’t fired anymore)?* > > No. > > 1. *Is there a list of this restricted set domains with which you’re > experimenting?* Want to know if ours are included > > The ls not ready yet, we'll update this thread before going ahead. > 1. *We should have `pagehide` replacement by Dec, is that too late?* > - Or would we have to join the dep trial to avoid our current > workflows being messed up? If so, how do we join? > > The earliest version this will be enabled in is M120 which released in Jan. So that should be safe https://chromiumdash.appspot.com/schedule F > > On Wednesday, October 25, 2023 at 4:31:38 AM UTC-7 Fergal Daly wrote: > >> On Wed, 25 Oct 2023 at 05:28, Kevin D. <kevin.de...@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/CAAozHLnvRTs%3D0XXPPP3dAJMrYkNJcZWhuPT9%2BjXE_%2BL1TJe0xA%40mail.gmail.com.
