LGTM3 On Sat, Oct 9, 2021, 01:49 Alex Russell <slightly...@chromium.org> wrote:
> 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/CAL5BFfXuKZFOUM8POTmKeM3t3Zz_LJOj0Z8bgzUxcLM52Kp77Q%40mail.gmail.com.
