firstUIEventTimestamp not set to the first event start time

[rviscomi]

In this example (trace) of an attribution object from web-vitals.js, there's one LoAF entry whose firstUIEventTimestamp value is 503383.2999999523. However, the first event entry in the frame, a pointerdown event, has a startTime of 502891.89999997616. The firstUIEventTimestamp in LoAF is actually much closer to—but not quite the same as—the pointerdown's processingStart time of 503383.59999996424.

The explainer describes firstUIEventTimestamp as:

// Time of the first UI event (mouse/keyboard etc.) to be handled during the course of this // frame. The timestamp is the event's // timestamp, i.e. the time it was queued // which could be long before it was processed.

So I'd expect it to be exactly 502891.89999997616, the startTime of the first event entry.

[mmocny]

Mostly I would expect this is a chromium bug, but I do have some spec questions that this raises:

Would we expect this to be the time of the first event dispatched in the animation frame, or, the time of the first event created and then dispatched at any time in the frame.

(Event dispatch can get re-ordered in limited ways, based on priority or vsync alignment or how synthetic gestures are layered.)

In the chromium implementation we just take the platform timestamp of the first UI event dispatched, and don't use the earliest value of any UIEvent dispatched (and I guess those values are also wrong somehow).