Closed Bug 59225 Opened 24 years ago Closed 24 years ago

event.keyCode doesn't return expected value?

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 58709

People

(Reporter: ekrock, Assigned: joki)

References

()

Details

Attachments

(1 file)

Using N6 11/1 on WinNT 4.0 SP6. The above test page claims to test support for the onkeypress attribute. In IE 5.5, you can press the numbers on the keyboard (except 4) and be taken to the appropriate page by the onkeypress handler, which changes the page location. In N6, pressing the number keys has no effect. I suspect this is because the W3C DOM2 specifies a different way of accessing the value of the key that was pressed than event.keyCode, which is what this demo depends on. Can someone (a) confirm this, and (b) tell me what alternative properties of the event object that the developer should use to access the value? Or is the problem that this relies on the existence of a global event object attached to the window object (which is an ie-ism) and that in N6 the event can't be accessed in this way? In that case, is the answer to receive the event object passed into the handler function as an argument and access it that way?
this is probably a duplicate of another bug that was filed in the last few weeks... I'd *guess* that the fix is to access "charCode" rather than "keyCode" I do NOT know if this stuff actually made it into any type of specification or not so I'm not sure if we're "right" or "wrong" or just "different" :-/
There are 2 problems: 1) The key events spec from the W3C DOM Group did not go out with DOM Level 2. We implemented a version of it that is now obsolete. Our implementation is also compatible with Nav 4.x. To get the character code of the key pressed, you can either use event.which (Nav 4.x terminology) or event.charCode (Nav 6 only way). event.keyCode is an IE-ism that we actually do implement for keyup and keydown events, but not for keypress events. 2) The test also makes the assumption, as Eric speculated, that the IE-specific window.event exists. The test should include an "event" parameter to the function gototest. I'm attaching a version that does work...
Yes, I believe it is a duplicate of 58709. If you think not, or that I'm rushing to conclusions, slap me. *** This bug has been marked as a duplicate of 58709 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
vrfy
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: