PerformanceEventTiming.interactionId

[sefeng211]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: PerformanceEventTiming.interactionId
• Specification or proposal URL (if available): https://w3c.github.io/event-timing/#dom-performanceeventtiming-interactionid
• Explainer URL (if available): https://github.com/w3c/event-timing/blob/main/interactionID-explainer.md
• Proposal author(s) (@-mention GitHub accounts): @mmocny
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @sefeng211 @smaug----
• WebKit standards-position:

Other information

[smaug----]

Is there some explanation what is the use case for this?

[sefeng211]

Here's the explainer https://github.com/w3c/event-timing/blob/main/interactionID-explainer.md

[smaug----]

It is not very well defined what is a "user interaction".

[mmocny]

Hey folks, thank you for taking a look and providing feedback here!

The interactionID-explainer.md that Sean linked is an older document. I think it still does a good job summarizing the motivations, but not the latest details, and doesn't try to specify the semantics at all. We could update it, but I think that document is largely been obsoleted.

---

Let me take a stab at making a quick summary of things here:

Goal: A single "Interaction" should map to a single user "gesture" such as a Click, Tap, or Keypress.

• Developers would like a simple way to measure Interaction Responsiveness in these terms, because thats what really matters to users.
• interactionId is a label, which helps developers focus on the most critical event timings, and/or critical moments within the overall performance timeline
  • i.e. Beyond just looking at the literal Event Timings with interactionId, it's common to use find overlapping LoAF API entires, or custom User Timings, or even other Event Timings, etc, to paint a whole story together.
• A single "Interaction" might cause any number of distinct events.
  • Some events are contextual. For example, beforeinput, input, change...
  • Some events are not "Interactions". For example, pointerenter, pointerexit...
  • Some events are conditionally "Interactions". For example, pointerdown might become a scroll or a tap, or a drag. You have to wait and see. We differentiate by checking if pointercancel follows.
    • FYI: Event Timing API already needs to do this for first-input event timing. I just tested FF nightly and it already works.
  • Event Timing API filters out a lot of events (e.g. due to minimum durationThreshold) even when these are observed by the browser internally.

Net/net, its not possible for a developer to just figure this out using the raw Event Timing API, but it is relatively easy for the Event Timing API to do it internally (as it already needs to observe these events) and expose hints via interactionId.

How?

• a new unique interactionId is assigned to each Event Timing that was involved in a shared user gesture, which we consider to be a new unique "Interaction". Typically there will be multiple events for a single interactionId.
• Pointer events already have pointer_id, and keyboard events already have key_codes, which already go a long way to helping group interactions.
• A single pointer_id or key_code can of course be the source of many distinct interactions over time. You can detect this by looking at the flow of events (i.e. new pointerdown or new keydown).
• The order of events that gets dispatched is fairly well specified, and the Event Timing spec already has a published algorithm for how to compute interaction id out of the stream of event timings, which it already observes.

---

In full transparency, the Chromium implementation has gone through some iteration over the last year as we discovered various details. Much of this is just internal complexity, but I do think it would be worthwhile for me to audit and update the Event Timing spec to document the latest implementation updates in Chromium, in case we have deviated and/or need to add extra clarity. (I.e. cases like composition events for virtual keyboards)

I would love to work with @sefeng211 (I assume?) to make sure this matches FF behaviour well.

Also, eventually, we might want to consider moving the specification of this concept up out of Event Timing and into e.g. UI Events spec itself (See: w3c/event-timing#114, w3c/event-timing#49). Then we can leave the Event Timing as just measuring and reporting rather than also defining.

---

There have been many other docs published that summarize motivations, and summarize some developer feedback, for example:

• https://web.dev/articles/inp
• https://web.dev/blog/responsiveness
• https://web.dev/blog/better-responsiveness-metric

[smaug----]

Click is not a user interaction. Click is an event dispatch based on (mouse/pointer)down/up events, or keypress. The draft probably needs some work.

[mmocny]

(I meant clicking on a physical mouse, which generates a stream of events, rather than just the click event type.)

[smaug----]

Right, but the draft spec talks about click event.

[mmocny]

Hey @smaug---- I might be misinterpretting your feedback, apologies if so.

Let me try one more time to clarify:

Event Timing spec modifies DOM event dispatch algorithm where we add a call to compute interactionID and then use that to initialize event timing. The finalize event timing steps also include some handling for interactionID (potentially that could be refactored a bit).

The following event types are are currently specced as involved in computing interactionID:

• pointerdown
• pointerup
• pointercancel
• keydown
• keyup
• compositionstart
• input
• click

...with clear steps for how a flow of events maps to new interaction ids.

Some of those events are not themselves assigned an interactionId but are used to determine if other events do get one.

---

In Chromium we currently found it useful to observe the following stream of events in practice, in addition to the above:

• contextmenu (in chromium we found we don't dispatch pointercancel in this case)
• keypress (this might just be internal chromium detail, as input should suffice)
• compositionupdate
• compositionend (these helped assign ids in certain IME input cases)

I haven't audited to know if the above are chromium specific, due to existing event dispatch warts, or if the spec should be updated.

[smaug----]

So chromium is not following the current spec if it follows only some of the events? Why does it have different behavior than the spec draft?

[mmocny]

So chromium is not following the current spec if it follows only some of the events?

It follows all the events currently in the spec. We additionally found that observing a small number of extra events helped disambiguate some cases and/or improve metrics reporting in small ways.

Why does it have different behavior than the spec draft?

This is not a desired gap. We should update draft spec (or chromium implementation), and I can try to do that. (I will take your feedback as a signal to prioritize that work.)

FWIW, most of the changes are minor (such as contextmenu being an alternative to pointercancel because we learned that pointer events don't dispatch pointercancel for that use case). This doesn't change the api, or even the types of events which expose interactionId, just clarifies the mechanism used to define interactions.

[mmocny]

Also: related to interactionId is interactionCount which is just a count of unique interactions.

Event Timing already has eventCounts which Mozilla implements, but a distinct interactionCount is needed for similar reasons to why interactionId is needed, to augment raw event timings / aggregate counts.

[smaug----]

I think we could be positive on this, but the spec needs tweaks so that implementations can be interoperable.