New issue
Advanced search Search tips

Issue 623414 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Viewing info about DOM node associated with Events in the Timeline

Reported by trusktr@gmail.com, Jun 26 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce the problem:
1. Record with Timeline.
2. Make events happens (move mouse, click things, etc).
3. Stop recording.
4. Look at an event in the timeline, and note that it doesn't give you any info about the DOM node that the event happened on.

What is the expected behavior?
We need info.

What went wrong?
No info is provided.

Did this work before? N/A 

Chrome version: 51.0.2704.103  Channel: n/a
OS Version: OS X 10.10.2
Flash Version: Shockwave Flash 22.0 r0

It would be great to get a reference (if the app still has a reference) to the DOM nodes that events happen on so we can further investigate. If the DOM node is no longer in the app (app has no references to it and it would be GCed, perhaps use a WeakMap to contain the DOM nodes in Timeline so they can be collected when the app doesn't use them any more), then it would be useful to at least show an HTML snippet that represents the DOM node as it was at that point in time so we can see the element name along with attribute names and values.

This would be super helpful in helping developers determine where events are coming from and would improve debugging.
 
Cc: alph@chromium.org
Owner: caseq@chromium.org
Status: Assigned (was: Unconfirmed)
caseq, alph: You think it may be possible to attach a DOM node id into the trace event?

trusktr, I imagine you'd want the event.currentTarget?

Comment 2 by trusktr@gmail.com, Jul 2 2016

@paul, I suppose event.currentTarget would help find the code that ran in the timeline, while event.target could help find the originating UI component. I'm not sure which is better, it might depend on the specific case. Maybe showing info for both might be an option?
Status: Archived (was: Assigned)
Bulk DevTools triage, closing low priority issues with no action plan.

Sign in to add a comment