Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which target could we expose in Event Timing? #838

Open
npm1 opened this issue Feb 28, 2020 · 6 comments
Open

Which target could we expose in Event Timing? #838

npm1 opened this issue Feb 28, 2020 · 6 comments

Comments

@npm1
Copy link
Contributor

npm1 commented Feb 28, 2020

This is not an issue, but rather requesting some help to figure out how to integrate a new feature of Event Timing properly with DOM. We'd like to add the event's target to improve attribution of the API: see w3c/event-timing#9 or w3c/event-timing#60. I'm aware that we should only expose the 'top-level' Event target: if an event is re-targeted and there are targets in shadow DOM then those won't be exposed. However, I'm having a hard time parsing the event dispatch algorithm to understand which is the target I'd like. Is https://dom.spec.whatwg.org/#concept-event-dispatch only called once per event (and re-targeting happens internally), and hence target the object I want?

@annevk
Copy link
Member

annevk commented Mar 2, 2020

I don't think you've given enough information. To answer this one would need to know at least:

  • Which events?
  • How are they dispatched? (I.e., with what settings.)
  • How are they meant to be exposed? (Timing, place, etc.)

@npm1
Copy link
Contributor Author

npm1 commented Mar 2, 2020

Which events: https://wicg.github.io/event-timing/#sec-events-exposed. Note that we expose first-input (where the types are a subset of those) always, and slow events.

How are they dispatched: I don't understand this question. "They" = the events? I suspect the answer to that would be in the corresponding event's spec.

How are they meant to be exposed: similar to other performance entries, we have a PerformanceEventTiming object which is exposed on a size-bounded array on the performance timeline and exposed to a PerformanceObserver, both of which are exposed to Window. In terms of the timing, we expose once the information on the update the rendering step after event handlers have ran, so that we can expose the 'next paint' after those handlers have ran.

@annevk
Copy link
Member

annevk commented Mar 2, 2020

How they are dispatched is somewhat relevant as it could affect whether they leave the shadow tree or not. It also seems you'd have to patch all the places where they are dispatched in order to collect them for a report.

@npm1
Copy link
Contributor Author

npm1 commented Mar 2, 2020

That information can be obtained via event.composed, no? There's no need to patch all the places. When event.composed is false and the target is in the shadow DOM, we cannot expose a target so it should return null.

@annevk
Copy link
Member

annevk commented Mar 4, 2020

How can you collect them without patching the dispatch places?

@npm1
Copy link
Contributor Author

npm1 commented Mar 4, 2020

They are dispatched from the DOM event dispatch algorithm, so again, that's the only thing that needs to change. What would I need to change from, for example, https://w3c.github.io/uievents/#event-type-mousedown?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants