Reputation: 1140
I fell foul of a Firefox keydown
behavior in that pressing the enter key (indeed any key) without having focus on a specific field will NOT trigger a keydown
event it will only trigger a `keypress event.
This could be very confusing as the keydown
and keyup
event use JavaScript key codes whereas keypress
uses ASCII codes. Fortunately 13 (enter/return) is common to both.
Is there any known reason why Firefox using keypress
in this circumstance? What is the benefit?
Once this was established IE8 threw up a silly in that it does not permit preventDefault
demanding instead returnValue = false
the following snippet from another Stack Overflow post has proved very useful:
event.preventDefault ? event.preventDefault() : event.returnValue = false;
During the search to resolve these issues I have been consistently confused by event.keycode
vs event.which
. Namely am I doing wrong using a switch statement similar to:
$("#class_Name").bind("keydown", function(event){
// do not test input if field controls used
switch(event.which){
case 13:
//enter key
event.preventDefault ? event.preventDefault() : event.returnValue = false;
break;
}
$("body").keypress(function(event){
// stop inadvertant form submission
if (event.keycode == "13"){
event.preventDefault ? event.preventDefault() : event.returnValue = false;
}
});
Upvotes: 20
Views: 16764
Reputation: 19644
According to this comment jQuery can be unreliable and this page says:
event.which
is undefined in IE<9 on keydown
and keyup
.
event.keyCode
is 0 in Gecko (Seamonkey, Firefox) on keypress
for keys that return a character.
event.charCode
is only supported on keydown and keyup by Internet Explorer (Mac).
Upvotes: 9
Reputation: 2015
Some browsers use keyCode
and others use which
. But with jQuery this is normalized so you don't have to think about that. You can just choose the one you prefer.
Upvotes: 11