We have it working and will be adding it very soon. It will also be very easy for library authors to add their own event parsers to our tools.
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.
My Visual Event tool makes use of that:
* https://sprymedia.co.uk/article/Visual+Event+2
* https://github.com/DataTables/VisualEvent
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.