Understood.
1. *Is there any action required from us until general rollout (when
`unload` isn’t fired anymore)?*
2. *Is there a list of this restricted set domains with which you’re
experimenting?* Want to know if ours are included
3. *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?
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/6a809b23-73b2-410f-bf91-d675be233087n%40chromium.org.
