#670: InteractionID in Event Timing

Visit on Github.

Opened Aug 23, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of InteractionID in Event Timing.

Currently, developers can measure the latency of an event using the Event Timing API. Developers may query the duration, which returns the next paint after event handlers have run. Or they may compute the input delay, the delta between startTime (the event's timeStamp) and processingStart, which is a timestamp taken right before event is dispatched. But measuring event latency separately can’t help developers fully understand the user’s pain. When a user interacts with a web page, a user interaction (i.e. click/tap, press a key, drag) usually triggers a sequence of events. For example, when the user clicks, several events will be dispatched: pointerdown, pointerup, mousedown, mouseup, click, etc. Therefore, we propose to measure the latency of the whole user interaction by aggregating associated events’ latencies. To calculate an interaction-level latency, there should be a way to group events or to tell if two events are fired by the same user interaction. We propose adding a new ID in PerformanceEventTiming named Interaction ID. Each Interaction ID will represent a unique user interaction. And events triggered by an interaction will share the same Interaction ID.

  • Explainer¹ (minimally containing user needs and example code): url
  • Security and Privacy self-review²: url
  • Primary contacts (and their relationship to the specification):
    • Nicolás Peña Moreno (@npm1, Google)
    • Hongbo Song (@debugtive0517, Google)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Chromium impl bug

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): W3C Web Perf
  • Existing major pieces of multi-stakeholder review or discussion of this design: this was presented to the WebPerf WG, see minutes
  • Major unresolved issues with or opposition to this design: N/A
  • This work is being funded by: Google

You should also know that this feature is part of the larger project on a new responsiveness core web vital which improves upon first input delay, and we have published our current thoughts on a blog post.

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @npm1

Discussions

Comment by @caraitto Sep 7, 2021 (See Github)

@npm1 For the InteractionID generation, I think we might want to clarify that if a random number generator is used, the RNG internal state shouldn't be shared across origins, to prevent sites from correlating IDs generated on different origins for the purposes of cross site tracking.

Comment by @npm1 Sep 8, 2021 (See Github)

@npm1 For the InteractionID generation, I think we might want to clarify that if a random number generator is used, the RNG internal state shouldn't be shared across origins, to prevent sites from correlating IDs generated on different origins for the purposes of cross site tracking.

Yes, the idea will be to keep a "user interaction value" in each Window.

Comment by @caraitto Sep 8, 2021 (See Github)

@npm1 For the InteractionID generation, I think we might want to clarify that if a random number generator is used, the RNG internal state shouldn't be shared across origins, to prevent sites from correlating IDs generated on different origins for the purposes of cross site tracking.

Yes, the idea will be to keep a "user interaction value" in each Window.

I don't see "user interaction value" in the explainer -- is this like a seed used to generate all the InteractionIDs generated for a given Window?

Comment by @npm1 Sep 8, 2021 (See Github)

Yea, it's not on the explainer, it's only in the spec PR. I clarified in that question that the random number would not be reused across frames.

Comment by @caraitto Sep 8, 2021 (See Github)

Yea, it's not on the explainer, it's only in the spec PR. I clarified in that question that the random number would not be reused across frames.

Cool, I think that addresses the issue. Could you post a link to the spec PR? Thanks :)

Comment by @npm1 Sep 8, 2021 (See Github)

https://github.com/WICG/event-timing/pull/102

Comment by @caraitto Sep 8, 2021 (See Github)

Thanks, that spec PR looks fine to me.

Discussed May 23, 2022 (See Github)

Dan: the last time this was touched was Sept 2021.. it's been bumped. Somebody needs to look at this.

Rossen: still relevant?

Peter: it was an early review when it came it. Looks like it's been merged into their event timing spec a month after they opened it

Dan: it's in WebPerf [leaves comment]

Comment by @torgo May 25, 2022 (See Github)

Hi @npm1 we're just trying to make some progress on this. Apologies it's taken so long. Is there any update you can share on the status - particularly multistakeholder status?

Comment by @npm1 May 25, 2022 (See Github)

Transferring this review to @mmocny

Discussed Aug 15, 2022 (See Github)

closed as timed out

Comment by @torgo Aug 15, 2022 (See Github)

Hi folks - at this point we're going to close this as timed out just clear up our backlog. However, please ping us to re-open when you'd like our feedback.