[whatwg] Detecting eventListeners

[Xavier Ho]

Hello Glenn,

On 25 May 2012 13:27, Glenn Maynard <glenn at zewt.org> wrote:

> The basic argument against it is that attaching an event listener that
> doesn't do anything is currently guaranteed to be a complete no-op in all
> cases.  That is,
>
> element.addEventListener("anything", function() { }, false);
>
> is guaranteed to have no side-effects and to do nothing at all.  Making
> event listeners enumerable would remove that property.
>

Interesting.  Thanks for sharing it.  I can't think of a good reason why
this guarantee is useful, though.


> I'm not personally concerned about that invariant, and I've wanted this in
> the past myself (though honestly I don't recall off-hand what for).
>

Good to hear.

>
>
> On Thu, May 24, 2012 at 9:33 PM, Jason Edward 今井 Parrott <
> parrott.jason at gmail.com> wrote:
> On Thu, May 24, 2012 at 10:00 PM, Xavier Ho <contact at xavierho.com> wrote:
>
>>  The door's already open.  You simply have to iterate through all the
>> nodes, and call removeEventListener with all possible events.
>>
>
> Actually, you can't, since you can't remove an event without a reference
> to the callback to pass to removeEventListener.
>

Strange.  I'm under the impression that simply calling

element.removeEventListener('click')

works, but that might have been my misunderstanding.  I'll have to
experiment a little to make sure my understanding is correct.


>
> On Thu, May 24, 2012 at 10:07 PM, Xavier Ho <contact at xavierho.com> wrote:
>
>> A very common use-case is to record a mouse click on a DOM element which
>> may fire an event on the page.  We want to capture clicks that actually
>> triggered an event, does a HTTP request, and so on, but not meaningless
>> clicks on an empty region.
>>
>> That said, there is no way of surely determining if a click is meaningful.
>>  We check if the DOM element clicked on is a button, a link (has href),
>> has
>> onclick attribute set, and so on.  However, this will fail on sites that
>> binds 'click' via 'addEventListener' on a strange element, like a <span>
>> or
>> a <em> tag.
>>
>
> This will also fail if the event handler is up the node tree.  That's very
> common with the event delegation pattern, where a capturing event listener
> for is registered for a container object (even on the document).  You have
> no way of knowing whether it'll actually do anything for any particular
> element.  I don't think this is a realistic use case.
>

 We already handle this for a number of libraries like jQuery.  This is
easily solved by traversing towards the root node and look for patterns
that match the library version.  Having read-access to eventListeners on
elements would have made it much easier, though!

Cheers,
Xav