Cap INP breakdowns to INP duration

[tunetheweb]

Fixes #492

Modals (alert(), confirm(), print()) do give feedback to the user, but also block the main thread so the event processing doesn't end when this shows. However, from an INP point of view, the feedback is given and so the duration is set to that timestamp.

I think it should be possible add a test case for this, but wanna agree on the change before going to that effort.

[mmocny]

I made some nit comments, but pre-approving.

Probably best to validate carefully...

[mmocny]

I think this is a fine temporary solution, but, consider just creating a variable such as "used_fallback_time", set up top when endTime < processingEnd, and re-use that everywhere.

(The goal is to expose a clue to event timing for this value, eventually.)

BTW the case where endTime is rounded to within 8ms of processingEnd is almost always another "used_fallback_time" example (i.e. when we actually dont have a paint)

[tunetheweb]

I'd prefer not to do that variable name. We haven't used a fallback time — Event timing has. We are always using the actual time given by that.

The current wording is similar to the LCP implementation in #527

[mmocny]

Thats fine.

---

The goal for Event Timing will be to:

• Expose presentation_time (possibly as renderTime to match other paint timing specs)
• Expose fallback_time (might be named something else)
• duration will be based on fallback_time || presentation_time, which is already is under the hood, but now you will know why.

Also, in hindsight, my suggestion of comparing with processingEnd only works if your event listener(s) caused the alert, but wouldn't work if some other task in the same animation frame did. Nor would it work for other cases of fallback_time like when you don't need next paint, or the page unloaded and hit visibilitychange as an alternative end time...