diagnostic · one of 50 free, no counter
Listener map
Which event handlers are attached to this element, and above it?
A click that does something nobody can find usually has a listener three ancestors up. This lists what is attached to the element you select and to every ancestor that carries anything: inline on* handlers, readable at any time, and every addEventListener call made after you press Record, with its event type, its capture and passive flags and the script that registered it - so a delegated handler shows up on the container that actually holds it.
Reach it Press ⌘ + K on any tab and type listener map. Ctrl + K on Windows and Linux
in the panel · free, no counter
What this actually is
inline handlers and listeners added after record, on an element and its ancestorsWhen a click, a key or a scroll does something and the code responsible is not where you looked, when a widget seems to answer twice, or when checking that a scroll handler is passive. It sees what is added after Record, so it is at its best on the action that wires things up - opening a menu, mounting a widget - or after a reload with Record on.
Asked about this diagnostic
3 of themWhy does it not show the listeners devtools shows?
Because devtools has getEventListeners and nothing else does: a browser does not let a page, or an extension reading one, list the listeners already attached to an element. So this is honest about its two sources - the inline attributes it can read, and the calls it watched being made after Record. An empty list means none seen, not none attached.
How do I catch the handlers a framework attached at load?
Press Record, then reload the page or remount the part you care about, so the framework's addEventListener calls happen while the wrapper is listening. On a page that attaches everything once at startup and never again, inline handlers are all it can show until that happens.
Why is the handler listed on a parent and not on the button I clicked?
Because that is where it is. Delegation - one listener on a list or on the document that checks event.target - is how most frameworks and many hand-written pages handle clicks, and it is exactly the case a search through the button's own attributes misses. The ancestors are listed for that reason.
how to use listener map
- Open Listener map and press Record before the page wires its handlers.
- Use the page - open the widget, mount the view - so its addEventListener calls are seen.
- Select an element with Inspect, then read its listeners and each ancestor's.
- Press Stop, and the page's own addEventListener is put back.
101 of these · no host permissions · three free audits