onKeyPress event.which sets non-alphanumerics to 0 (Enter, ESC, Backspace, etc)




Event Handling
18 years ago
14 years ago


(Reporter: Ariel Shkedi, Assigned: joki (gone))



Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
The onKeyPress event is not capturing 'Enter' (and others) correctly. It does
capture the event, but it does not set 'event.which' correctly - it is set to 0
instead of 13. The same is true for ESC and lots of others.

In addition the 'tab' keypress is captured as well - unlike all the other
browsers, and probably a bug. But in any case it too sets 'event.which' to 0.

There are a lot of other keys you can try as well, F1, backspace, NumLock even!

It is probably a separate bug regarding the fact that it captures nearly every
key on the keyboard, so with a bit of JavaScript, you can prevent a user for
doing almost anything. Is there a spec that says which keys are capturable?

But in any case, if it does capture a keystroke, it should at least set the code

I will upload an attachment with some HTML to test this.

Comment 1

18 years ago
Created attachment 13462 [details]
onKeyPress event capture and keycode test

Comment 2

18 years ago
Changing status to New
Ever confirmed: true

Comment 3

18 years ago
event.which is an old event property from 4.x which is being deprecated.  
Mozilla supports both event.keyCode and event.charCode where keyCode identifies 
the key numerically and charCode identifies the character entered (if any.  
for example ESC generates no character to the screen so it has a charCode of 
0.  It does, however, have a keyCode of 27).  event.which was loosely mapped to 
whichever seemed to apply more correctly but since event.which only worked in 
4.x and the keys you mentioned didn't generate events in 4.x there is no 
compatibility problem.  If you want the values you can check the new props.

Unfortunately I wish I could say go look at DOM Level 2 Events for this stuff 
but the key event portion of that spec was pulled at from DOM Level 2 to DOM 
Level 3 so doesn't exist and this stuff is based on that key event draft.  So 
for now you kind of either have to look at the DOM source code or just kind of 
know.  Not a great solution but we're working on it.

As to which keys should generate events the answer is the spec more or less says 
all of them should.  It leaves security to the browser vendors.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 4

18 years ago
So you are saying there are 4 different way to get the key pressed?

event.which (NS)
window.event.keyCode (IE)

Which of these are part of the spec? Which ones does Mozilla support?

What about the problem of keystrokes showing up on the screen even though the 
event handler returns false?

Later I'll write a full testcase for each permutation, because I still think 
there is a bug - but I'll repoen if I can verifiy it. But could you tell me 
which methods listed above Mozilla supports, and which ones the spec says?

So that I can make a test matrix of which ones are supposed to work.

Comment 5

18 years ago
Updating QA Contact.
QA Contact: janc → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 7

17 years ago
QA contact updated
QA Contact: gerardok → madhur


16 years ago
QA Contact: madhur → rakeshmishra


16 years ago
QA Contact: rakeshmishra → trix

Comment 8

14 years ago
*** Bug 231142 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.