67233 - Inconsistently applying keyCode/charCodes

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Jeff Yates]

While reviewing the charCode and keyCode property of the event object I have
noticed that the values are inconsistantly applied.  A good example is (assuming
 "^" represents the control key) ^c returns a charCode of 99 (the "c"
character), but ^[ returns a keyCode of 27 (escape character).  If alpha
characters used in combination with the control key return the alpha character,
then the symbolic characters in combination with the control key should return
the symbolic character!

I think that control + key combination should ALWAYS return the keycode in order
to separate them from the normal pressing of a key.  This may also be true of
the alt key, but not as importantly as the character key since the control + key
combinations have pre-defined meanings in ASCII.

In a way I think it "might" be best if a keyCode is always provided, and a
charCode only provided when a displayable key has been pressed.

Jeff Yates.

Comment 1

[Jeff Yates]

Also note that CapsLock Control + a returns the same value as without the
CapsLock.  I do not know if this is intentional or not!  I am only compairing it
to IE (which returns different values depending upon CapsLock).

Jeff Yates

Comment 2

[Johnny Stenback (:jst)]

Reassigning to joki

Comment 3

[Jeff Yates]

I have been reviewing my ASCII and I go back on part of what I was saying.

I said:
    I think that control + key combination should ALWAYS return the keycode in
    order to separate them from the normal pressing of a key.  This may also be
    true of the alt key, but not as importantly as the character key since the
    control + key combinations have pre-defined meanings in ASCII.

I have found that it would be useful to distiguish between the enter key and
control+M combination of keys.  But I have found that control+pause returns the
same as control+C.  The inconsistancy is that the enter key returns a keycode
and control+pause returns a charCode and control+enter returns a character code.

I am sure there are other examples of this.  I think the best solution would be
to have both a keyCode and a charCode returned on all of those occations where a
special function key is currently returning a charCode (including the number key
pad).

Talking about the Number Key Pad, when numLock is on, pressing 1 does not return
a character code for 1, but a keyCode.  The same is true for all of the number
pad keys exept the enter key.  !!!!!!This also should be changed!!!!!!!!

Sorry to harp:)

Jeff.

Comment 4

[Keyser Sose]

Moving & Marking NEW.

Comment 5

[Matthew T (active 1999-2002)]

Um, Keyser, what does this have to do with user interface design?

--> Event Handling

Comment 6

[Madhur Bhatia]

QA contact updated

Comment 7

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 8

[Theo Brinkman]

I'm getting similar activity in some scripts I'm writing.  Sometimes, when I
capture event.which for insert, delete, home, end, pageup, pagedown, etc... I
get 0 (for all of them), other times, I get 45, 46, 36, 35, 33, and 34 respectively.

When I get the non-zero values, and I look in event.keyCode, I see 0.
If this isn't a bug, what am I doing wrong?  If this is a bug, I'd think it's a
fix  that should make it into 1.0.0!

Comment 9

[Theo Brinkman]

Ignore my last note.  I discovered the cause, and it was my code.
I used '(objEvent.which)?objEvent.which:objEvent.keyCode);' when I should have
used '("undefined" !== typeof objEvent.which)?objEvent.which:objEvent.keyCode);'

Comment 10

[Pham]

.

Comment 11

[Vedran Miletic]

retargeting

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Starting 15, bug 630810 fix makes keyCode computed from unshifted input character for printable keys. So, this bug must be a part of bug 630810.