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.
On Thu, Oct 7, 2021 at 2:15 PM Alex Russell <slightly...@chromium.org> wrote: > 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? > > > On Thursday, October 7, 2021 at 7:17:01 AM UTC-7 Nicolás Peña wrote: > >> 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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs> >>>> >>>> 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. >> >> >>> >>> >>>> >>>> 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://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> >>>> 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 >>>> <https://www.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 blink-dev+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec282b39-cd45-46f1-a542-cbdc7354347an%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. 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.
