Closed Bug 58709 Opened 24 years ago Closed 24 years ago

onkeypress: the keyCode for the Return key is 0

Categories

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

defect

Tracking

()

VERIFIED DUPLICATE of bug 62878

People

(Reporter: pierre, Assigned: joki)

References

()

Details

Attachments

(2 files)

Tested with recent trunk and branch builds on the Mac and Win98.

- Go to http://home.netscape.com/
- Click the WebMail icon at the top
- Enter your name and password (or any name and password)
- Type the Return key
==> Nothing happens. You must click the "Sign In" button to log in.

The cause of the bug is:
If you attach a 'onkeypress' handler to an editable field, the key code you 
receive for the Return key is 0 instead of 13. It works correctly for every other 
key.

Notes:
- In M16, it was the opposite: the key code for every key was 0, except for the 
Return key where it was 13.
- CCd mjudge who allegedly worked in that area.
on a keypress event, you should be looking for the charcode, not the keycode (at
least for return and alphanumeric characters).
This is a duplicate of bug 58444
I thought this sounded familiar.  :-)

*** This bug has been marked as a duplicate of 58444 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
*** Bug 58444 has been marked as a duplicate of this bug. ***
Hey, this is fun! We managed to dupe two bugs at the same time. Now both are
dupes :)

Well, I am reopening this one since this points to a high visibility site.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 59309 has been marked as a duplicate of this bug. ***
enyee@zdnetmail.com (Ken Yee) wrote in the Duplicate bug:
function processKeyPress( key_pressed )
{
    var key;

    if ( document.all )
 key = window.event.keyCode;
    else
 key = key_pressed.which;

    if ( key == 13 )
 document.form_login.submit();
}
*** Bug 59225 has been marked as a duplicate of this bug. ***
Well I think the initial intent of this bug was slightly off.  The keyCode for
the Return key is in fact 13 these days but the Netscape login page still
doesn't work, mainly because I would guess it's looking for event.which, which
is 0 in this case.  That's really due to a more or less designed behavior change
in 6.0 but since event.which is just a 4.x compat. thing I don't mind hacking it
up a bit to make it work.

In any case, that specific aspect of the bug is covered in 62878.  I'm going to
go ahead and dupe this one now.

*** This bug has been marked as a duplicate of 62878 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
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
QA Contact: gerardok → madhur
QA contact updated
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
verified dupe
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

Created:
Updated:
Size: