Thanks for clarifying that you're thinking about this problem, Nicolás. Looking forward to seeing more of that land in future intents.
LGTM2 On Thursday, October 7, 2021 at 5:44:37 PM UTC-7 Chris Harrelson wrote: > LGTM1 > > On Thu, Oct 7, 2021 at 1:15 PM Nicolás Peña <n...@chromium.org> wrote: > >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAATDi%3DVRz7iztxqUQbS_UhP_9ez-pfVE%2B4w4aXj%2Bn%3Dc7hf8xg%40mail.gmail.com?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/18afb412-0220-4b97-a368-484828b01755n%40chromium.org.
