RESOLVED FIXED 167077
Web Inspector: Event Listeners detail section is unhelpful, default should show listeners by element rather than by event 
https://bugs.webkit.org/show_bug.cgi?id=167077
Summary Web Inspector: Event Listeners detail section is unhelpful, default should sh...
Blaze Burg
Reported 2017-01-15 14:33:45 PST
When I have an element selected, I want to know what listeners are installed on that element and maybe set a breakpoint or see the listener source. This is extremely hard to do right now as you need to expand every DOM event section, manually check if the listener is for the selected element, etc. I think the default should behave more like on ObjectTree, where first we show the object, then its prototype properties, and so on. If we think the existing behavior is interesting, say to show what listeners should fire before or next, then we can keep that as a toggle. In my experience, I've only ever wanted to know the list of eligible event listeners while I was debugging into one of them. I'll file a separate bug about that.
Attachments
Patch (12.09 KB, patch)
2017-03-10 16:18 PST, Devin Rousso 		no flags
DetailsFormatted DiffDiff
[Image] After Patch is applied (55.48 KB, image/png)
2017-03-10 16:19 PST, Devin Rousso 		no flags
Details
Patch (22.04 KB, patch)
2017-03-10 21:02 PST, Devin Rousso 		no flags
DetailsFormatted DiffDiff
[Image] After Patch is applied (59.58 KB, image/png)
2017-03-10 21:03 PST, Devin Rousso 		no flags
Details
Patch (22.04 KB, patch)
2017-03-11 10:52 PST, Devin Rousso 		no flags
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2017-01-15 14:34:02 PST
<rdar://problem/30033633>
Devin Rousso
Comment 2 2017-03-10 16:18:52 PST
Created attachment 304093 [details] Patch
Devin Rousso
Comment 3 2017-03-10 16:19:15 PST
Created attachment 304094 [details] [Image] After Patch is applied
Joseph Pecoraro
Comment 4 2017-03-10 17:44:05 PST
I'm not sure I like this. I find it very useful to know the event listener dispatch order. Meaning, for a click event the exact order that event listeners will fire: (1) the use capture listener on the <body> (2) the on target event listener on me (3) some event listener bubbling on an ancestore etc. This change would remove that information which I find useful and is not available anywhere else. --- To address Brian's concerns, it seems we could have a way to filter the EventListeners section to only show events that ultimately have a listener registered on the current selected node. And to make the UI highlight in some way the event listeners that are on the selected node. This gets the best of both worlds.
Devin Rousso
Comment 5 2017-03-10 21:02:42 PST
Created attachment 304127 [details] Patch
Devin Rousso
Comment 6 2017-03-10 21:03:03 PST
Created attachment 304128 [details] [Image] After Patch is applied
Devin Rousso
Comment 7 2017-03-11 10:52:48 PST
Created attachment 304167 [details] Patch
Joseph Pecoraro
Comment 8 2017-03-13 11:27:05 PDT
Comment on attachment 304167 [details] Patch r=me, you may want to check with Brian that this satisfies his use case
WebKit Commit Bot
Comment 9 2017-03-13 15:29:50 PDT
Comment on attachment 304167 [details] Patch Clearing flags on attachment: 304167 Committed r213874: <http://trac.webkit.org/changeset/213874>
WebKit Commit Bot
Comment 10 2017-03-13 15:29:54 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.