core(cls): ignore `had_recent_input` by timing window

[adamraine]

Proposal that closes https://github.com/GoogleChrome/lighthouse/issues/14396

See my comments for #14396 for the reasoning.

[connorjclark]

Perhaps we should consider the alternative approach mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=1094974#c19 , which both annie and yoav vouched for–do our emulation resizing and wait 500ms before navigating to the page.

[paulirish]

IMO this a chromium bug. It shouldn't treat a window resize in a previous navigation as "recent input".

https://bugs.chromium.org/p/chromium/issues/detail?id=1302667#c21

[adamraine]

IMO this a chromium bug. It shouldn't treat a window resize in a previous navigation as "recent input".

I agree this should no longer close https://github.com/GoogleChrome/lighthouse/issues/14396, but it's still better that what we had before.

[connorjclark]

Can you confirm the delta in the sample json tests are expected?

[connorjclark]

Although this PR is strictly better, we want to rid ourselves of our hacky "ignore had_recent_input.... sometimes" approach entirely. And we are hesitant to do the 500ms-waiting approach before about:blank nav.

We need to address this as a chromium bug (ref).

Maybe we can determine when the cutoff for CLS events by looking at the navigation (or timespan equivalent) timestamp?

[adamraine]

Can you confirm the delta in the sample json tests are expected?

The delta in the JSON is not expected. I'm going to ping upstream for help.

[adamraine]

I did some investigation. Instead of looking at LS events within 500ms of the time origin, we should look at LS events within 500ms of the first "viewport" event.

Even though emulation is started before navigating, Chrome still triggers a viewport update event after the navigation starts which gets treated as an interaction for LS had_recent_input purposes: https://bugs.chromium.org/p/chromium/issues/detail?id=1302667#c19