#670: InteractionID in Event Timing
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)
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.
OpenedAug 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.
Further details:
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