On Wed, 8 Nov 2023 at 21:07, Fergal Daly <fer...@google.com> wrote: > > > 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. >
The origins come from this list top 50 websites https://en.wikipedia.org/w/index.php?title=List_of_most-visited_websites&oldid=1198053805 > > >> 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 > This is actually going to arrive in M122 and will be visible to canary/dev users right around now, F > > > 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/CAAozHLmySXTWGuDy%3D75Csa2F1npx8XuCSu%2Bt9KRmYmMrVEt9UQ%40mail.gmail.com.
