We Keep Coding

Multiple JS event handlers on single element

I am working with an existing web app, in the app there are a variety of submit buttons on different forms, some using regular http post, some defining an onClick function, and some binding a js event handler to the button using a class on the element.
What I want to do, is bind another event handler to these buttons by just adding a class to the buttons, but what I want to determine is will the new event handler be guaranteed to be executed, or could one of the form submit actions happen before it does meaning my new function isn't hit.
The example scenario is I want to add a class to these buttons that bimds them all to a common js function that simply logs usage to some api. Is there a risk that the logging function isn't called because the form submit has navigated away from the page?
I've not done loads of js development, and I could test this 100 times over and just get lucky with it firing.
Below is some code I have tested with for one of the examples - again, I'm not asking how to bind multiple events, the question is to about my understanding of the spec and whether execution of all handlers is guaranteed.
$(document).ready(function(){
$('.testingBtn').click(function() {
window.location.replace("http://stackoverflow.com");
});
$( ".testingBtn" ).click(function(){
alert('submitting!');
});
});
<input class="testingBtn" type="submit" id="submitform" value="Complete Signup" />
As seen above, I can bind the multiple events, and in this example, just directed to another url, but this could be a form.submit() etc. In my testing the alert has always fired first, but am I just getting lucky with the race conditions?

In JS, you don't really have control over what order the event handlers are called, but with careful delegation and well-placed listeners, it is possible.
Delegation is one of the most powerful features of the event model. As you may or may not know: in JS, an event is handed to the top of the dom, from where it propagates down to the element onto which the event should be applied. It stands to reason, therefore, that an event listener attached to the global object will call its handler prior to a listener that has been attached to the element itself.
window.addEventListener('click',function(e)
{
e = e || window.event;
var target = e.target || e.srcElement;
console.log('window noticed you clicked something');
console.log(target);//<-- this is the element that was clicked
}, false);//<-- we'll get to the false in a minute
It's important to note we actually have access to the event object in the handlers. In this case, we left the event object untouched, so it'll just continue to propagate down to the target, on its way down, it might meet with something like this:
document.getElementById('container').addEventListener('click', function(e)
{
e = e || window.event;
var target = e.target || e.srcElement;
if (target.tagName.toLowerCase() !== 'a' || target.className.match(/\bclickable\b/))
{
return e;//<return the event, unharmed
}
e.returnValue = false;
if (e.preventDefault)
{
e.preventDefault();
}
}, false);
Now, this handler will be called after the listener at the window level calls its helper. This time, the event is changed if the clicked element didn't have the clickable class, or the element is a link. The event is canceled, but it lives on, still. The event is still free to propagate further down the dom, so we might encounter something like:
document.getElmentById('form3').addEventListener('click',function(e)
{
e = e || window.event;
if (e.returnValue === false || e.isDefaultPrevented)
{//this event has been changed already
//do stuff, like validation or something, then you could:
e.cancelBubble = true;
if (e.stopPropagation)
{
e.stopPropagation();
}
}
}, false);
Here, by calling stopPropagation, the event is killed off. It can't propagate further down the dom to its target unless the event was already altered. If not, the event object travels further down the DOM, as if nothing happened.
Once it reaches its target node, the event enters its second phase: the bubble phase. Instead of propagating down into the deeps of the DOM, it climbs back up, to the top level (all the way to the global object, where it was dispatched... from whence it came and all that).
In the bubble phase, all the same rules apply as in the propagation phase, only the other way around. The event object will encounter the elements that are closest to the target element first, and the global object last.
There's a lot of handy, and clear diagrams for this here. I can't put it any better than good 'ol quirksmode, so I suggest you read what they have to say there.
Bottom line: when dealing with 2 event listeners, attach them both on a different level to sort-of queue them the way you like.
If you want to guarantee both are called, only stop the event from propagating in that handler that will be called last.
When you've got two listeners, attached to the same element/object for the same event, I've never come across a situation where the listener that was attached first, wasn't also called first.
That's it, I'm off to bed, hoping I made sense

jQuery makes this easy.
$(document).on('click', '.someclass', function() {
doStuff();
});
$(document).on('click', '.someclass', function() {
doMoreStuff();
});
Handlers then both will fire on click. jQuery keeps a queue of handers for you. And handles document clicks that match a selector of your choice so that they can be triggered no matter when your buttons are created.

I am/was having a similar issue as this. However I can not affect the order of/delegate the pre-existing 'click' events (added by Wicket framework).
But I still need to execute a new custom event before any of the 'click' or 'change' events handled by the framework.
Luckily there are several events that are actually executed in order. The 'mousedown' and the 'mouseup' happens to happen before the 'click'.
http://en.wikipedia.org/wiki/DOM_events
$(document).on('mousedown', function (event) {
event = event || window.event
var target = event.target || event.srcElement;
console.log(target + ' before default event'); // Hold mouse button down to see this message in console before any action is executed
});
OR
$(document).on('mouseup', function (event) {
event = event || window.event
var target = event.target || event.srcElement;
alert(target + ' before default event'); // You may not notice this event fires when the page changes unless this is an alert
});
This will allow the logging to be done (e.g. via ajax) before the actual event is executed e.g. a page change via (ajax) link.
Of course you may need to have more sophisticated means to detect for what the additional event handling should be done, but you can use for example the 'target' information for this. => This script monitors everything on the page, as this is how I need this to be done.

jQuery stopPropagation is ignored

My goal is to prevent all the click events (hiding/showing of elements in the HTML when clicked) unless a certain condition is met (the user has a certain word in an input element).
So i tried to add that logic to the click handler of the document or "html" but the click handler of the other element fired first because of bubble up.
So i tried attaching that logic to "*", and now that click handler fires first- but propagates it to the the other element too, ignoring stopPropagation, preventDefault and return false.
$(document).ready(function(){
$("*").click(function(event){
if ($("#user").val() !== "admin"){
console.log("1");
event.stopPropagation();
event.preventDefault();
return false;
}
});
$("#user").click(function(event){
console.log("2");
// do something
});
});
Why "2" is written to the console after "1" when there shouldn't be any further propagation because of return false/stopPropagation?
How else can i achieve my goal using jQuery?
Thanks!

stopPropagation() prevents the event propagating any further up the ancestor tree. However, it doesn't prevent the remaining event handlers on the current from being fired.
To do this (prevent further propagation and prevent any further event handlers on the current element from being fired), you need to call stopImmediatePropagation() (instead, not as well).
Attaching an event handler to every element in this manner, and calling stopImmediatePropagation() (as well as preventDefault()) will prevent all clicks from having an effect; providing no event handlers are bound before (as handlers are executed in order; you can't undo a handler which has already fired).
This doesn't make it nice though, as finding, enumerating over, and attaching a handler to every element is pretty costly.
To make it nicer, your options are either:
Attach a click event to document, and simply preventDefault() and sacrifice stopImmediatePropagation().
Check the state of #user in each event handler; you can ease the pain of this by rolling your own wrapper function;
function checkUserState(then) {
return function () {
if ($("#user").val() !== "admin") {
then.apply(this, arguments);
}
};
};
... use like so;
$("#user").click(checkUserState(function(event){
console.log("2");
}));
As noted in the comments, I'm purposefully avoiding the suggestion of using event delegation, as whilst allows attaching only one event handler instead of n, it doesn't allow you to stopPropagation() of events.

preventDefault() doesn't prevent the action

When I use event.preventDefault() on a link it works, however when I use it on a button doesn't!
DEMO
My code:
<a id="link" href="http://www.google.com">link</a>
<button id="button" onclick="alert('an alert')">button</button>​
$('#link').click(function(event){
event.preventDefault();
});
$('#button').click(function(event){
event.preventDefault();
});
​
Link action is cancelled, but when I click on the button, still executes the onClick action.
Any help? what I want to do is to prevent the button onClick action without changing the button html (I know how to do
$('#button').removeAttr('onclick');

You want event.stopImmediatePropagation(); if there are multiple event handlers on an element and you want to prevent the others to execute. preventDefault() just blocks the default action (such as submitting a form or navigating to another URL) while stopImmediatePropagation() prevents the event from bubbling up the DOM tree and prevents any other event handlers on the same element from being executed.
Here are some useful links explaining the various methods:
http://api.jquery.com/event.preventDefault/
http://api.jquery.com/event.stopPropagation/
http://api.jquery.com/event.stopImmediatePropagation/
However, since it still doesn't work it means that the onclick="" handler executes before the attached event handler. There's nothing you can do since when your code runs the onclick code has already been executed.
The easiest solution is completely removing that handler:
$('#button').removeAttr('onclick');
Even adding an event listener via plain javascript (addEventListener()) with useCapture=true doesn't help - apparently inline events trigger even before the event starts descending the DOM tree.
If you just do not want to remove the handler because you need it, simply convert it to a properly attached event:
var onclickFunc = new Function($('#button').attr('onclick'));
$('#button').click(function(event){
if(confirm('prevent onclick event?')) {
event.stopImmediatePropagation();
}
}).click(onclickFunc).removeAttr('onclick');

you need stopImmediatePropagation not preventDefault. preventDefault prevents default browser behavior, not method bubbling.
http://api.jquery.com/event.stopImmediatePropagation/
http://api.jquery.com/event.preventDefault/

The preventDefault function does not stop event handlers from being triggered, but rather stops the default action taking place. For links, it stops the navigation, for buttons, it stops the form from being submitted, etc.
What you are looking for is stopImmediatePropagation.

you can try this:
$('#button').show(function() {
var clickEvent = new Function($(this).attr('click')); // store it for future use
this.onclick = undefined;
});
DEMO

It have helped me
function goToAccessoriesPage(targert) {
targert.onclick.arguments[0].preventDefault();
...
}

event.preventDefault() and multiple events

Before I start writing huge swathes of code that don't work I thought I'd ask this question.
event.preventDefault() only cancels the default action of the click event doesn't it?
Theoretically I should be able to bind mutiple click event handlers in jQuery to a given target to perform different actions like Ajax posts and Google tracking.
Am I wrong?

event.preventDefault() only cancels the default action of the click event doesn't it?
It cancels the browser's default action of the event (not just the click event) (W3C docs, jQuery docs). So for instance, in the form submit event, it prevents the form being submitted by the browser. It doesn't stop anything you're doing in code, and it doesn't stop bubbling; that's what stopPropagation is for (W3C docs, jQuery docs).
So say you have a link in a div, and you have the click event hooked on both the link and the div. If the link's event handler calls preventDefault, the browser won't do its default action (following the link), but the event continues to bubble up the DOM to the link's parent element, the div, and so you'll see the event on your click handler there, too. Any actions you're taking in code in either handler will be unaffected by your calling preventDefault.
In your comment below, you ask about multiple handlers on the same element. Neither preventDefault nor stopPropagation affects those, they'll still get fired...unless you use stopImmediatePropagation, which tells jQuery to stop the event dead in its tracks (but doesn't prevent the browser's default action).
I should probably round this out by saying that if you return false from your event handler, that tells jQuery to prevent the default and stop bubbling. It's just like calling preventDefault and stopPropagation. It's a handy shortcut form for when your event handler is taking full control of the event.
So, given this HTML:
<div id='foo'><a href='http://stackoverflow.com'>Q&A</a></div>
Example 1:
// Here we're preventing the default but not stopping bubbling,
// and so the browser won't follow the link, but the div will
// see the event and the alert will fire.
$("#foo").click(function() {
alert("foo clicked");
});
$("#foo a").click(function(event) {
event.preventDefault();
});
Example 2:
// Here we're stopping propagation and not preventing the default;
// the browser will follow the link and the div will not be given
// a chance to process the event (no alert, and more to the point,
// code in the div's handler can't prevent the default)
$("#foo").click(function() {
alert("foo clicked");
});
$("#foo a").click(function(event) {
event.stopPropagation();
});
Example 3 (you'll only rarely see this):
// Here we're doing both, and so the browser doesn't follow the
// link and the div doesn't see the event (no alert).
$("#foo").click(function() {
alert("foo clicked");
});
$("#foo a").click(function(event) {
event.preventDefault();
event.stopPropagation();
});
Example 4:
// Shorter version of Example 3, exactly the same effect
$("#foo").click(function() {
alert("foo clicked");
});
$("#foo a").click(function() {
return false;
});

In JavaScript event handling, why "return false" or "event.preventDefault()" and "stopping the event flow" will make a difference?

It is said that when we handle a "click event", returning false or calling event.preventDefault() makes a difference, in which
the difference is that preventDefault
will only prevent the default event
action to occur, i.e. a page redirect
on a link click, a form submission,
etc. and return false will also stop
the event flow.
Does that mean, if the click event is registered several times for several actions, using
$('#clickme').click(function() { … })
returning false will stop the other handlers from running?
I am on a Mac now and so can only use Firefox and Chrome but not IE, which has a different event model, and tested it on Firefox and Chrome by adding 3 handlers, and all 3 handlers ran without any stopping…. so what is the real difference, or, is there a situation where "stopping the event flow" is not desirable?
This is related to
Using jQuery's animate(), if the clicked on element is "<a href="#" ...> </a>", the function should still return false?
and
What's the difference between e.preventDefault(); and return false?

hopes this code can explain it to you...
html
<div>
click me
click me
</div>​
jquery
$('div').click(function(){
alert('I am from <div>');
});
$('a.a1').click(function(){
alert('I am from <a>');
return false; // this will produce one alert
});
$('a.a2').click(function(e){
alert('I am from <a>');
e.preventDefault(); // this will produce two alerts
});​
demo
or
$('div').click(function(){
alert('I am from <div>');
});
$('a').click(function(){
alert('I am from <a>');
});
$('a.a1').click(function(){
alert('I am from <a class="a1">');
return false;
});
$('a.a2').click(function(e){
alert('I am from <a class="a2">');
e.preventDefault();
});​
demo 2

Writing return false or e.preventDefault() will not prevent other handlers from running.
Rather, they will prevent the browser's default reaction, such as navigating to a link.
In jQuery, you can write e.stopImmediatePropagation() to prevent other handlers from running.

return false and preventDefault() are there to prevent the browser's default action associated with an event (for example, following a link when it's clicked). There is a different technique to achieve this for each of three different scenarios:
1. An event handler added using addEventListener() (non-IE browsers). In this case, use the preventDefault() method of the Event object. Other handlers for the event will still be called.
function handleEvent(evt) {
evt.preventDefault();
}
2. An event handler added using attachEvent() (IE). In this case, set the returnValue property of window.event to true. Other handlers for the event will still be called, and may also change this property.
function handleEvent() {
window.event.returnValue = false;
}
3. An event handler added using an attribute or event handler property.
<input type="button" value="Do stuff!" onclick="return handleEvent(event)">
or
button.onclick = handleEvent;
In this case, return false will do the job. Any other event handlers added via addEventListener() or attachEvent() will still be called.
function handleEvent() {
return false;
}

Sometimes an event listener wants to cancel the sideeffects of the event is is interested in. Imagine a textbox which you wish to only allow numbers. Because textboxes can accept anything it becomes necessary to tell the browser to ignore non numbers that are typed. This is achieved by listening the key events and returning false if the wrong key is typed.

This doesn't completely answer your question, but the other day I used YUI's e.preventDefault() on an <a> element to squash the href action, as I only wanted the JavaScript onclick event to have control (unless no JS detected). In this situation stopping the entire chain of events wouldn't effect me.
But a couple days before that, I had an <input type="checkbox"> nested inside a <label> element, and I had to use a conditional in the event handler to determine if the clicked target was a label, as neither e.preventDefault() nor e.stopEvent() stopped my 'click' event from (legitimately) triggering twice (except in IE6).
What would have been nice is the ability to squash an entire chain of related events, since I'd already tried propagation and return false ;, but I was always going to get a 2nd event fire thanks to my label element.
Edit: I wouldn't mind knowing how jQuery would've handled my double-event situation, if anyone's keen to comment on that.