Summary: | Web Inspector: Event Listeners detail section is unhelpful, default should show listeners by element rather than by event | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | BJ Burg <bburg> | ||||||||||||
Component: | Web Inspector | Assignee: | Devin Rousso <hi> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | commit-queue, hi, inspector-bugzilla-changes, joepeck, webkit-bug-importer | ||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | All | ||||||||||||||
Attachments: |
|
Description
BJ Burg
2017-01-15 14:33:45 PST
Created attachment 304093 [details]
Patch
Created attachment 304094 [details]
[Image] After Patch is applied
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. Created attachment 304127 [details]
Patch
Created attachment 304128 [details]
[Image] After Patch is applied
Created attachment 304167 [details]
Patch
Comment on attachment 304167 [details]
Patch
r=me, you may want to check with Brian that this satisfies his use case
Comment on attachment 304167 [details] Patch Clearing flags on attachment: 304167 Committed r213874: <http://trac.webkit.org/changeset/213874> All reviewed patches have been landed. Closing bug. |