As usual, the event listeners shown are just jQuery making the binding. It would be really great if it actually stepped back through the stack to see what initially called jQuery's bind. I can't think of any general solution to the problem that covers all libraries, but jQuery is so ubiquitous it should be worthwhile.
In Chrome Devtools debugger, you can click on the Async checkbox next to where the call stack is. So, when paused, you can see the full stack. (If you are not on the latest chrome, this might need to be enabled in experiments).
And this show why it is a bit difficult to choose what to show, among all the things from the call stack (including async stuff) that triggered something. For one thing you could possibly ignore libary code (e.g. http://www.divshot.com/blog/tips-and-tricks/ignoring-library... ) but if you have a medium to big SPA with many backbone/wreqr events, let's say, you would still need to look in the stack manually.
Perhaps they could make it ignore blackboxed scripts by emitting a fake event and waiting until a non-blackboxed call is made, then intercepting that call and showing that function as the actual listener? That idea falls apart of the blackboxed listener changes the state of the program, though.
Or maybe an extra argument to addEventListener that takes a reference to a function that is the "real" listener? Then libraries like jQuery would just pass the user-provided function along in their own code.
I found that (in some browsers - not all) that calling `toString()` on the function that has been attached (which you can get by poking around in the jQuery cache) returns the raw, formatted, function - with comments, etc. You can then do a simple `indexOf()` on the `textContent` of the `<script>` tag (for loaded scripts I do an Ajax get to pull in the text of the script, which isn't perfect since remote domains fail, but its a start).
The end result is that, when possible (Safari and Chrome) the script will tell you where the event listener was bound.
I haven't looked into it, but I presume the Firefox dev tools are using information directly from the DOM, since they have access to that. But there is no public interface in DOM to get the event listeners for a node, which I cursed at the time, but in retrospect it makes the above possible.
