Bug 167077 - Web Inspector: Event Listeners detail section is unhelpful, default should show listeners by element rather than by event
Summary: Web Inspector: Event Listeners detail section is unhelpful, default should sh...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-01-15 14:33 PST by BJ Burg
Modified: 2017-03-13 15:29 PDT (History)
5 users (show)

See Also:


Attachments
Patch (12.09 KB, patch)
2017-03-10 16:18 PST, Devin Rousso
no flags Details | Formatted Diff | Diff
[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 Details | Formatted Diff | Diff
[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 Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description BJ Burg 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.
Comment 1 Radar WebKit Bug Importer 2017-01-15 14:34:02 PST
<rdar://problem/30033633>
Comment 2 Devin Rousso 2017-03-10 16:18:52 PST
Created attachment 304093 [details]
Patch
Comment 3 Devin Rousso 2017-03-10 16:19:15 PST
Created attachment 304094 [details]
[Image] After Patch is applied
Comment 4 Joseph Pecoraro 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.
Comment 5 Devin Rousso 2017-03-10 21:02:42 PST
Created attachment 304127 [details]
Patch
Comment 6 Devin Rousso 2017-03-10 21:03:03 PST
Created attachment 304128 [details]
[Image] After Patch is applied
Comment 7 Devin Rousso 2017-03-11 10:52:48 PST
Created attachment 304167 [details]
Patch
Comment 8 Joseph Pecoraro 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
Comment 9 WebKit Commit Bot 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>
Comment 10 WebKit Commit Bot 2017-03-13 15:29:54 PDT
All reviewed patches have been landed.  Closing bug.