Intent to Prototype: Exposing a string targetIdentifier attribute to EventTiming performance entries.

[Michal Mocny]

Contact emails

mmo...@google.com

Explainer

https://github.com/w3c/event-timing/pull/160

Specification

https://github.com/w3c/event-timing/pull/160

Summary

The Event Timing API is part of the Performance Timeline and is used to measure the performance of user interactions. Each entry already report a `target` value, alongside the event timing information, which can be useful for attribution. However, because observing performance entries is asynchronous, and potentially buffered, and because the `target` value is a weak reference -- by the time the Event Timing entry is observed, we might have already disconnected the node from the dom, and will now have a null `target` value. This issue affects other performance apis which report on live nodes (e.g. element timings) but seems to be especially common for event timing, since the result of dispatching events will commonly modify the page in ways that remove the element that was used (e.g. clicking "close" or "accept" buttons will remove the UI). For this reason, it is useful to capture a string identifier to represent the EventTarget at the time of event dispatch (and measurement). For now, this is a very simple string such as `tagName#id`. Note: This also matches (and was borrowed from) the behaviour of the Long Animation Frame Timing API, for setting the `invoker` value of PerformanceScriptTiming when `invokerType` is an `event-listener`.

Blink component

Blink>PerformanceAPIs

Web Feature ID

event-timing

Motivation

One of the more common developer paint points, and thus feedback, about Event Timing is that it can be hard to debug/diagnose when the event timing target value is empty, and this offers no remedy to reproduce locally. A workaround that is sometimes used is to save a targetIdentifier string value by registering event listeners, creating a map of all events and event target strings, and then later merging this with Event Timing entries once reporting from the performance api -- but this mostly negates the advantages of using the performance API in the first place.

Initial public proposal

https://github.com/w3c/event-timing/issues/126

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: A top feature request for Event Timing API (see https://github.com/w3c/event-timing/issues/126 and through various feedback channels).

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None

Debuggability

None

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

Not yet, but the Event Timing api itself is covered by tests, and the first prototype CL updates and adds to WPT as needed.

Flag name on about://flags

None

Finch feature name

EventTimingTargetIdentifier

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5143499213242368?gate=6159368701739008

This intent message was generated by Chrome Platform Status.