Intent to Ship: interactionID in Event Timing

98 views
Skip to first unread message

Nicolás Peña

unread,
Oct 4, 2021, 1:13:50 PMOct 4
to blink-dev, Hongbo Song
Contact emails

n...@chromium.org, hbs...@chromium.org


Explainer

https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777


Specification

https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid


Summary

Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.


Blink component

Blink>PerformanceAPIs


TAG review

https://github.com/w3ctag/design-reviews/issues/670


TAG review status

Open


Risks
Interoperability and Compatibility

The main interop risk is that this feature does not become implemented in other browsers. This is an attribute in a performance feature so even if this is not implemented there websites using this feature should not break in any way.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/283) Updated the Event Timing issue to note this addition.


WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) This is a negative on Event Timing as a whole, so we consider this to be negative for this feature in particular.


Web developers: No signals. We presented this to WebPerf WG https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html 


Ergonomics

N/A



Activation

Seems tricky to impossible to polyfill, so developers would need to use the API in order to obtain the more accurate data. 



Security

One consideration was whether it is ok to expose the number of interactions that have occurred in the page. This is already observable via event handlers. Cross-origin events are not exposed.



Debuggability

Use PerformanceObserver in the console. We don't have concrete plans to add Event Timing support in DevTools yet, but maybe in the future. Lab tools in general do not currently have great support for user inputs.


Is this feature fully tested by web-platform-tests?

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html 


Flag name

InteractionId


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1236758


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1245771


Estimated milestones

96


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5674224959094784


This intent message was generated by Chrome Platform Status.


Michal Mocny

unread,
Oct 4, 2021, 1:19:37 PMOct 4
to Nicolás Peña, blink-dev, Hongbo Song
On Mon, Oct 4, 2021 at 1:13 PM Nicolás Peña <n...@chromium.org> wrote:
Contact emails

n...@chromium.org, hbs...@chromium.org


Explainer

https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777


Specification

https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid


Summary

Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.


Blink component

Blink>PerformanceAPIs


TAG review

https://github.com/w3ctag/design-reviews/issues/670


TAG review status

Open


Risks
Interoperability and Compatibility

The main interop risk is that this feature does not become implemented in other browsers. This is an attribute in a performance feature so even if this is not implemented there websites using this feature should not break in any way.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/283) Updated the Event Timing issue to note this addition.


WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) This is a negative on Event Timing as a whole, so we consider this to be negative for this feature in particular.

Do *not* consider this to be negative for this feature in particular, I think?
 

Web developers: No signals. We presented this to WebPerf WG https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html 


Ergonomics

N/A



Activation

Seems tricky to impossible to polyfill, so developers would need to use the API in order to obtain the more accurate data. 



Security

One consideration was whether it is ok to expose the number of interactions that have occurred in the page. This is already observable via event handlers. Cross-origin events are not exposed.



Debuggability

Use PerformanceObserver in the console. We don't have concrete plans to add Event Timing support in DevTools yet, but maybe in the future. Lab tools in general do not currently have great support for user inputs.


Is this feature fully tested by web-platform-tests?

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html 


Flag name

InteractionId


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1236758


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1245771


Estimated milestones

96


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5674224959094784


This intent message was generated by Chrome Platform Status.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec282b39-cd45-46f1-a542-cbdc7354347an%40chromium.org.

Nicolás Peña

unread,
Oct 4, 2021, 1:26:31 PMOct 4
to Michal Mocny, Nicolás Peña, blink-dev, Hongbo Song
On Mon, Oct 4, 2021 at 1:19 PM Michal Mocny <mmo...@google.com> wrote:


On Mon, Oct 4, 2021 at 1:13 PM Nicolás Peña <n...@chromium.org> wrote:
Contact emails

n...@chromium.org, hbs...@chromium.org


Explainer

https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777


Specification

https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid


Summary

Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.


Blink component

Blink>PerformanceAPIs


TAG review

https://github.com/w3ctag/design-reviews/issues/670


TAG review status

Open


Risks
Interoperability and Compatibility

The main interop risk is that this feature does not become implemented in other browsers. This is an attribute in a performance feature so even if this is not implemented there websites using this feature should not break in any way.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/283) Updated the Event Timing issue to note this addition.


WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) This is a negative on Event Timing as a whole, so we consider this to be negative for this feature in particular.

Do *not* consider this to be negative for this feature in particular, I think?

Since it is negative for Event Timing as a whole, I consider that to be negative by inheritance for this addition to Event Timing. If we think that this is not the case then I can ask but I don't think there will be a different answer.

Yoav Weiss

unread,
Oct 7, 2021, 1:58:59 AMOct 7
to Nicolás Peña, blink-dev, Hongbo Song
On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña <n...@chromium.org> wrote:
Contact emails

n...@chromium.org, hbs...@chromium.org


Explainer

https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777


Specification

https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid


Summary

Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.


Blink component

Blink>PerformanceAPIs


TAG review

https://github.com/w3ctag/design-reviews/issues/670


TAG review status

Open


Risks
Interoperability and Compatibility

The main interop risk is that this feature does not become implemented in other browsers. This is an attribute in a performance feature so even if this is not implemented there websites using this feature should not break in any way.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/283) Updated the Event Timing issue to note this addition.


WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) This is a negative on Event Timing as a whole, so we consider this to be negative for this feature in particular.


Web developers: No signals. We presented this to WebPerf WG https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html 

My read of the minutes is that there was a developer need for grouping interactions, but even more demand (at least from the folks in the room) for scroll grouping. Is that accurate?
 

Ergonomics

N/A



Activation

Seems tricky to impossible to polyfill, so developers would need to use the API in order to obtain the more accurate data. 



Security

One consideration was whether it is ok to expose the number of interactions that have occurred in the page. This is already observable via event handlers. Cross-origin events are not exposed.



Debuggability

Use PerformanceObserver in the console. We don't have concrete plans to add Event Timing support in DevTools yet, but maybe in the future. Lab tools in general do not currently have great support for user inputs.


Is this feature fully tested by web-platform-tests?

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/event-timing/click-interactionid.html 


Flag name

InteractionId


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1236758


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1245771


Estimated milestones

96


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5674224959094784


This intent message was generated by Chrome Platform Status.


Nicolás Peña

unread,
Oct 7, 2021, 10:17:01 AMOct 7
to blink-dev, Yoav Weiss, blink-dev, Hongbo Song, Nicolás Peña
On Thursday, October 7, 2021 at 1:58:59 AM UTC-4 Yoav Weiss wrote:
On Mon, Oct 4, 2021 at 7:13 PM Nicolás Peña <n...@chromium.org> wrote:
Contact emails

n...@chromium.org, hbs...@chromium.org


Explainer

https://gist.github.com/npm1/9c2b95ece116d9bcb4bc224155e23777


Specification

https://wicg.github.io/event-timing/#dom-performanceeventtiming-interactionid


Summary

Developers currently use the Event Timing API to gather performance data about events they care about. However, it is currently hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. The interactionID enables developers to link multiple PerformanceEventTiming entries when they correspond to the same user interaction.


Blink component

Blink>PerformanceAPIs


TAG review

https://github.com/w3ctag/design-reviews/issues/670


TAG review status

Open


Risks
Interoperability and Compatibility

The main interop risk is that this feature does not become implemented in other browsers. This is an attribute in a performance feature so even if this is not implemented there websites using this feature should not break in any way.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/283) Updated the Event Timing issue to note this addition.


WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031553.html) This is a negative on Event Timing as a whole, so we consider this to be negative for this feature in particular.


Web developers: No signals. We presented this to WebPerf WG https://w3c.github.io/web-performance/meetings/2021/2021-05-27/index.html 

My read of the minutes is that there was a developer need for grouping interactions, but even more demand (at least from the folks in the room) for scroll grouping. Is that accurate?

Yea, that is accurate.
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Alex Russell

unread,
Oct 7, 2021, 2:15:53 PMOct 7
to blink-dev, Nicolás Peña, Yoav Weiss, blink-dev, Hongbo Song
So this design looks pretty good in terms of auto-generating a uniform ID for pre-baked events, but I'm curious about how it will interact with asynchronous tasks generated from within task callbacks, and how a user-timing mark from within one of these scopes might inherit the interactionID?

Nicolás Peña

unread,
Oct 7, 2021, 4:15:03 PMOct 7
to Alex Russell, blink-dev, Nicolás Peña, Yoav Weiss, Hongbo Song
We do want to make it easier to track asynchronous work, and I think this will require something such as `measureUntil`. Once we implement that, it would be plausible to extend EventTiming to include that developer-annotated async duration. It would also make it possible to annotate any User Timing entries with the relevant interactionID. We're also thinking about heuristics to track asynchronous work automatically in a meaningful way. Without this, the annotations might be too noisy. For instance, a user input can trigger a long animation, and having the async duration be arbitrarily long or having the marks inside that animation be indefinitely tied to that interactionID seems odd.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Oct 7, 2021, 8:44:37 PMOct 7
to Nicolás Peña, Alex Russell, blink-dev, Yoav Weiss, Hongbo Song

Alex Russell

unread,
Oct 8, 2021, 7:49:01 PMOct 8
to blink-dev, Chris Harrelson, Alex Russell, blink-dev, Yoav Weiss, Hongbo Song, Nicolás Peña
Thanks for clarifying that you're thinking about this problem, Nicolás. Looking forward to seeing more of that land in future intents.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss

unread,
Oct 12, 2021, 1:08:15 PMOct 12
to Alex Russell, blink-dev, Chris Harrelson, Hongbo Song, Nicolás Peña
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages