• Can lifecycleactiveLength be lifecycleActiveLength?
• It's my understanding that this change is anticipated to be supported by Chrome only initially. I think that means we have to maintain the existing implementation but I wasn't quite clear from the meeting discussion.
• Does ResourceLoader instrumentation JavaScript loading order matter for these metrics?
• Is this just adding a single event listener? What is the scope of the actual changes we want to make here?

In T219212#5059359, @Niedzielski wrote:

• Can lifecycleactiveLength be lifecycleActiveLength?

Sounds good, I renamed it in the task description.

• It's my understanding that this change is anticipated to be supported by Chrome only initially. I think that means we have to maintain the existing implementation but I wasn't quite clear from the meeting discussion.

Yes, that's why the task decription said "in addition to visibleLength" (which will remain based on the Visibility API).

Background/motivation: A limitation of the current ReadingDepth data is that the pageUnloaded event may not be fired if the page is terminated by the browser/system before unload. On mobile, this actually happens in a majority of cases and biases our data especially when comparing reading times on desktop and mobile ( https://meta.wikimedia.org/wiki/Research_talk:Reading_time/Work_log/2018-11-02 ).

Indeed, Google's documentation cautions against using the "legacy" unload event (see https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid):

Many developers treat the unload event as a guaranteed callback and use it as an end-of-session signal to save state and send analytics data, but doing this is extremely unreliable, especially on mobile! The unload event does not fire in many typical unload situations, including closing a tab from the tab switcher on mobile or closing the browser app from the app switcher.

Furthermore, the mere presence of a registered unload event handler (via either onunload or addEventListener()) can prevent browsers from being able to put pages in the page navigation cache for faster back and forward loads.

The documentation recommends that we use the pagehide event wherever possible:

function onUnload( /* ... */ ) {
}

if ( window.hasOwnProperty( 'onpagehide' ) ) {
    $( window ).on( 'pagehide', ( e ) => {
      // The page isn't going to be persisted to the browser's BFCache and is about to be unloaded.
      if ( !e.persisted ) {
        onUnload( e );
      }
    } );
} else {
    $( window ).on( 'unload', onUnload );
}

This change should fix the issue identified in that work log.

☝️ If necessary, we could break out migrating from using the unload event to using the pagehide event into another task.

In T219212#5066829, @phuedx wrote:

☝️ If necessary, we could break out migrating from using the unload event to using the pagehide event into another task.

Yes, great point! I'm still slightly wondering about compatibility/comparability though - is it correct to interpret the documentation as saying that in cases where the unload event fires correctly, it should coincide with the pagehide event (with terminated state)?

@phuedx feel free to move this to triaged but future once some developer notes, AC and QA steps have been added!

In T219212#5070027, @Tbayer wrote:

Yes, great point! I'm still slightly wondering about compatibility/comparability though - is it correct to interpret the documentation as saying that in cases where the unload event fires correctly, it should coincide with the pagehide event (with terminated state)?

AIUI yes (except I believe a pagehide event with persisted = false would mean that an unload event should follow).

Additional notes that I raised during today's Backlog Grooming meeting:

• Page Lifecycle API - HTTP203: https://www.youtube.com/watch?v=UlLQPguE7UQ
• According to the above, session storage is persisted when the page is discarded
• If the browser supports the frozen event (i.e. onfreeze in document), then it supports session storage

This doesn't need analysis it just needs prioritization