31

The answer was "no" back in March 2010:

Browser EventListenerList Implementation

I'm wondering if there has been any progress since then.

If the answer's still "no" ... any indication of when any browser might support it?

Max Desiatov
  • 5,087
  • 3
  • 48
  • 56
jawns317
  • 1,726
  • 2
  • 17
  • 26

1 Answers1

33

For those looking for a practical solution, see: How to find event listeners on a DOM node when debugging or from the JavaScript code?


EventListenerList was in some old draft of DOM 3 Events and was long removed from the spec. As far as I know, at least Gecko still doesn't have anything like this for regular web pages, although it now has an API for privileged code (extensions) to enumerate listeners (see https://bugzilla.mozilla.org/show_bug.cgi?id=570678#c0).

I looked through the W3C mailing lists, and there were a few discussions on this topic, but apparently no use-cases were found to justify the feature. This is the most recent message I could find:

[...] what is the motivation for adding this functionality at all? Previously, the working group resolved to remove the related but less powerful hasEventListenerNS method for lack of a use case, and because there are potential security issues.

(2001) http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/thread.html#msg89 has some discussion from way back when the EventListenerList was considered.

(2006) http://lists.w3.org/Archives/Public/www-archive/2006Mar/0032.html asks a question to the author of quirksmode who seems to be responsible for the DOM3 EventListenerList myth about the use cases of such a feature; the archives do not list a reply.

(2008) another discussion: http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg66

Note: Commenting on my post is not a good way to provide feedback for the browser vendors and standards organizations. I'm not affiliated with either group, and I doubt they will see or act on the comments here..

Nickolay
  • 31,095
  • 13
  • 107
  • 185
  • If the handlers were registered using a JS library or you want this for debugging, see the answers for this question: http://stackoverflow.com/questions/446892/how-to-find-event-listeners-on-a-dom-node – Nickolay Oct 18 '11 at 23:06
  • 2
    It would be great with an update, if anybody is up to date with the status. Nowt it's 2015 :) – Mads Skjern Jul 19 '15 at 19:16
  • 3
    My use case is to clone an element and its event listeners. How is this not an obvious use case? – Nick Manning Aug 26 '15 at 20:41
  • 1
    @NickManning I'd recommend searching the W3C archives and posting your suggestion there. If you do that, please also comment with a link here for the benefit of others who are curious about the news on this topic. – Nickolay Aug 28 '15 at 00:46
  • 7
    that's weird they couldn't find *any* use-case. if i'm debugging a situation where a event seems not to be attached, it'd be useful to see what events *are attached*. or if i have a mixin that attaches events, unless one already exists, in which case it defers to the existing event. – worc Aug 07 '16 at 01:10
  • 5
    One use case would be accessibility testing: flagging or warning about click events on inaccessible elements. Really wishing this hadn't been removed. – Marcy Sutton Oct 10 '16 at 20:08
  • 10
    Another use case: I'm visiting a webpage that has an annoying event listener. I want to open my browser console and remove it. Or better yet, write a web extension that automatically removes this listener. – Rúnar Berg Jun 14 '17 at 11:57
  • I was looking for this for a general solution for `role="button"`. Currently w3c recommends adding not only an event handler for `click` but also for `Return` and `Space` keys, see https://www.w3.org/TR/wai-aria-practices/examples/button/button.html. However, instead of making the list of event handlers available it would IMHO be much better if w3c specified that the click handler should work for those keys too. – Leo Jun 13 '19 at 14:02