Event Capturing is near evil

Tuesday, May 15th, 2007

If you’re using a browser that implements the EventListener interface (W3 model), try this out for size

addEventListener useCapture

document.addEventListener('click', function(e) {
    e.stopPropagation();
    e.preventDefault();
}, true);

What do you think this will do? …Yeah, you’re right. If you have Firebug, copy the four lines above, then navigate to any webpage such as this one just for testing, open up your Firebug console command line, and paste it in there and run it. Now try clicking on any link in the document. Pretty sweet? Or almost near evil?

When Internet Explorer finally sports a W3 Event model, keep this little doozy in mind. I will admit, however, that there were times when I could have really used capturing, so don’t get the wrong impression. Cheers.

13 Responses to “Event Capturing is near evil”

Daniel
May 15th, 2007 at 11:03 am

document.body.onclick = function() { return false; }
Robert Otani
May 15th, 2007 at 11:17 am

I don’t know about “evil,” it seems like one of those things where you need to be “this tall” to be able to ride this roller coaster.
NIkola
May 15th, 2007 at 11:26 am

This could be a great time saver, I really like it. But I see this in internet production at the earliest 2009. Some intranet applications however could make use of it earlier though.
Wouldee
May 15th, 2007 at 12:01 pm

Uh … for us idiots … can you tell me what it’s suppose to do?

It doesn’t do anything as far as I can tell.
andyduncan
May 15th, 2007 at 12:38 pm

I guess it could be used for evil, but we use it (or various libraries’ versions of it) for “progressive enhancement” all the time. For example, a link that works as a link, unless you have javascript enabled, in which case it triggers some more fancy javascript code. As I’m typing this, I guess we could just return false, but that’s not always possible, and it would seem to have the same bad effects in many cases.
jason
May 15th, 2007 at 3:40 pm

The same thing happens if you set the parameter to true (bubble) and the anchor tag just has a normal href (no javascript event handler).

Because with bubble the order is
```
anchor handlers -> document handlers -> window handlers
```
and the event stop is after the anchor click handlers have been executed.
Anthony Ettinger
May 15th, 2007 at 4:21 pm

If I’m not mistaken, running the code then clicking on a link does nothing?

If that’s the case, then I agree with Robert’s statement about being “this tall” to use it.
Dustin Diaz
May 15th, 2007 at 4:41 pm

I think a few folks might have misunderstood the post. The point here is this. You can hijack (capture) all events and stop them from propagating at the document level. Comment #1 by Daniel isn’t even capable of doing this. If any elements had event listeners (or handlers) attached to them, they will not be dispatched. Eg:
```
<a onclick="alert('hello');" href="http://www.google.com">Gooooooooooogle</a>
<script>
    document.body.onclick = function() { return false; };
</script>
```
The above example will still alert “hello” when you click on the link. However, the code below, will not!
```
<a onclick="alert('hello');" href="http://www.google.com">Gooooooooooogle</a>
<script>
    document.addEventListener('click', function(e) {
        e.preventDefault();
        e.stopPropagation();
    }, true);
</script>
```
Essentially meaning that once a higher level element (or object) sets “capture” to true, it receives first precedence over its children. Take that a step further and call stopPropagation() and you’ve now hijacked any other events from that same type of event (in this case ‘click’).
Dustin Diaz
May 15th, 2007 at 4:48 pm

Anthony, I agree with Roberts comment as well. It is more or less a feature that should be used with caution (same goes for eval()). This example really has nothing to do with how links are not followed… but rather an example event capturing and propagation being stopped at a high level. If you had ‘click’ events assigned to an inner <div> element, but captured the ‘click’ event to an outer <div> element, the events assigned to the inner will not fire.
Nicholas
May 15th, 2007 at 4:53 pm

Don’t forget about IE’s setCapture() method. Not quite the same as the DOM event capturing, but can be just as evil.

All your clicks are belong to us!
Robert Otani
May 15th, 2007 at 5:33 pm

This also goes back to having to trust your source. For example, a not-so-cautious web developer may insert an external .js reference into his html. The JS may contain such an event capture method, and walla, she can track all sorts of behavior (or worse) on the victim’s site without knowing about it. Sounds evil to me, but again it brings things back to being “tall enough” to go on the ride…
Harvey
July 28th, 2007 at 11:51 am

This is all fine and cool stuff but what about capturing the onBlur of a Div tag? For that matter what about adding my own custom events? Any ideas…
big fan
August 16th, 2007 at 12:38 pm

Newbie alert:

How does one run the code once pasted into the console?

Perhaps someone can explain what it supposed to happen with and without the code?

Thanks!

./with Imagination