Here's something that I believe, should be included in dev tools: Click on a node, and see all event handlers that are attached to that node (and those attached using jQuery).
Maybe I'm missing something, but you'll find attached Event Listeners at the very bottom-right of the Elements panel, under where (Computed) Styles, Metrics, Properties, and DOM Breakpoints are found.
> Does anyone know if this is possible using Dev Tools?
The WDT puts that in the sidebar of the Elements tab, below Metrics.
These are usually completely unreadable as it's become rather common to 1. use a third-party DOM library (which will add indirections and essentially always bind the same thing) and 2. use delegation (which will bind on a far-removed parent of the element you've selected).
Firebug doesn't (as far as I know) do it natively, but FireQuery[0] adds a display hook to jQuery-bound events (and more), which may provide more and more useful information than the WDT on these (won't work if you're not using jQuery though)
It's possible, but not trivial. Especially when the developer is using 100% event delegation, you have to run that node against all the potential selectors of parent elements...
This is the main issue with trying to catalogue event handlers. Backbone.js, and savvy jQuery developers won't use bind for any sort of dynamic pages, because it's too hard to track handlers and make sure they're rebound properly as the DOM updates. The best solution is to use .on, which generally (argument specific) will set up a listener on a PARENT element of the selector you've put in.
.live() .delegate() and (usually) .on() will leave the handler on a parent node, making sniffing out all active handlers an expensive DOM-walking task.
Yes, but there is still a node that has an event listener on, and it is quite possible to display that in developer tools. Opera Dragonfly already does this, for example. What's not possible is for the browser to know that the event handler on element A only has any effect if the event occurs on descendant elements B and C, for example.
Given this limitation, the only problem with displaying event handlers is that developers who don't understand the underlying event model of the platform might not grasp the correspondence between the high-level abstractions in their library-using code and the low level DOM behaviour. Clearly any such developers will become more effective once they know a little more about the platform they are working on.
Does anyone know if this is possible using Dev Tools? There is a bookmarklet Visual Event2 (http://www.sprymedia.co.uk/article/Visual+Event+2) that does this, sort of; but it is still lacking.