126436 - the e.which property of an key event returns the wrong ascii code

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Stephan Lukits]

Well, the summary says actually everything. I  put a test case to it for
investigation.

Comment 1

[Stephan Lukits]

Attachment: The test case

Comment 2

[Phil Schwartau]

Confirming reported behavior on Mozilla trunk 2002021413 WinNT.
For example, the testcase expects 97 as the e.which for 'a'.
I get 65, which is the expected code for 'A'.

Browser, not engine ---> DOM Events.
OS: Linux ---> All.

Comment 3

[/\/\arcio Galli]

Attachment: smaller testcase demonstrating the exact thing.

Comment 4

[/\/\arcio Galli]

I will add a new testcase that demonstrates one case where e.which works.

(1) Basically it's not working for:
  - window.onkeyup=eventHandler;
  - window.onkeydown=evantHandler; 

(2) And it works for:
  - window.onkeypress=eventHandler;

In the second case, e.which have the proper values. 

Comment 5

[/\/\arcio Galli]

Attachment: Small ttestcase demonstrating that e.which is valid when the event handler is used for onkeypress

Comment 6

[Stephan Lukits]

It's still not the whole story. With the keypress event the escape
and caps-lock keys are not correct returned whereas they are correct
returned with the keydown and the keyup event. The function keys are
not correct returned by all three of them. Or to be more exact: keyup
and keydown return the wrong keys and keypress returns 0.

Comment 7

[Stephan Lukits]

I don't want to bother you but I wonder if I didn't understand the
event model right or if there is another bug. As I tried to change my
Application to the keypress event I figured out that this event does
not occur if the focus is in a forms selection control. I have in
my application some of them and wrote among other things a
functionality to make the selection controls smarter so that they not
only recognize the first character but all of them if they fit to the
beginning of a option value. And I actually don't want to put to each
selection control a onKeyPress event as this would be a waist of
resources, I think. I have a test case if you need one. But I'm not
sure if this should rather become a new bug therefore I wait for your respond.

Comment 8

[Stephan Lukits]

And again. When I add the onKeyPress event to my selection controls I get a js
error that e has no properties. E is the variable which should contain the key
code. So I'm at the beginning again :-(.

Comment 9

[Bob Clary [:bc] (inactive)]

man is this so uncool -> nsbeta1

Comment 10

[Stephan Lukits]

Sorry, I don't understand what you mean with this.

Comment 11

[Bob Clary [:bc] (inactive)]

I mean that this bug is bad and should be fixed. I have nominated it to be fixed
in the next netscape release. since i am here again, nominate for mozilla 1.0 as
well.

Comment 12

[Jaime Rodriguez, Jr.]

nsbeta1+ per ADT/Embed triage.

Is there a URL here? IS anyone still using this out in the wild? If yes, pls
renominate.

Comment 13

[saari (gone)]

I think Jaime meant nsbeta1-

Comment 14

[xavier.loup]

Attachment: Testcase for key press and key down

This testcase the difference between key down (wrong) and key press (ok)

Comment 15

[Simon Paquet [:sipaq]]

not a blocker.

Comment 16

[Samuel Sidler (old account; do not CC)]

*** Bug 284703 has been marked as a duplicate of this bug. ***

Comment 17

[[e-mail]]

In Gecko/Win, keydown events only know about scan codes. Only keypress events have had the necessary character code decoding applied.

It's possible that IE behaves differently here and generates duplicate events for keydown and keypress, whereas we generate a "real" keydown.

The W3C appears to be deprecating keypress in favour of keydown, although I've got no idea how we'd implement keyup in that model.

Comment 18

[Firefox Bug Husbandry Bot]

Bulk priority change, per :mdaly