*Contact emails* [email protected] *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 <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> *Web Feature ID* event-timing <https://webstatus.dev/features/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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* 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 <https://chromestatus.com/>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEeF2TfzH7wEOaLmr_b6DPCqhQxiXTThDGrMKGoRA-JnNudjPw%40mail.gmail.com.
