Intent to Ship: interactionID in Event Timing

[Nicolás Peña]

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]

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]

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]

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]

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]

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]

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]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAATDi%3DVRz7iztxqUQbS_UhP_9ez-pfVE%2B4w4aXj%2Bn%3Dc7hf8xg%40mail.gmail.com.

[Alex Russell]

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.

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.

--
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]

LGTM3

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.

--
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.