Closed
Bug 62878
Opened 25 years ago
Closed 25 years ago
event.which returns 0 for CR instead of 13
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: bsmith, Assigned: joki)
References
Details
Attachments
(2 files)
|
173 bytes,
text/html
|
Details | |
|
890 bytes,
patch
|
Details | Diff | Splinter Review |
1. In response to an onKeyPress event, the which property of the event returns
0 instead of 13 when a CR is entered. In NS 4.76, it returns the expected value
of 13.
Use the following code to reproduce the problem:
<HTML><BODY>
<FORM>
Type a character:
<INPUT TYPE="text"
SIZE=1
ONKEYPRESS="alert ('event.which = ' + event.which);return false">
</FORM>
</BODY></HTML>
2. Note also that after setting the keyboard focus to the input field, typing a
char, and clearing the alert window, typing another char does nothing. I can
only assume that the keyboard focus is no longer in the input field anymore
although the text cursor is blinking there. To repeat the test with another
char, you must once again click in the input field to set the keyboard focus
there. This behavior also is different from NS 4.76.
I encountered this bug in a real world application which traps the CR in the
text field in order to submit the form.
|
||
Comment 2•25 years ago
|
||
|
|
||
Comment 3•25 years ago
|
||
Using Mozilla builds 2000120908 on WinNT, Linux, 2000120817 on Mac.
Confirming behavior "1" above on all three platforms; changing OS to "All".
When I hit the "Enter" key, event.which comes up as 0.
Confirming behavior "2" on WinNT, but not on Linux or Mac.
Perhaps this should be filed as a separate bug?
Anyway, this is browser, not engine. Reassigning to Event Handling component
for further triage and analysis -
Assignee: rogerl → joki
Status: UNCONFIRMED → NEW
Component: Javascript Engine → Event Handling
Ever confirmed: true
OS: Windows 98 → All
QA Contact: pschwartau → lorca
|
|
Assignee | |
Comment 5•25 years ago
|
||
This is a compatibility issue with 4.x because we are attempting to move onto
newer and hopefully standardized versions of key events. Obviously we need to
keep 4.x stuff working too but without hacking things up event.which does
function differently in some cases than it did in 4.x. Doesn't mean we can't
fix them but still lower priority.
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
|
|
Assignee | |
Updated•25 years ago
|
Target Milestone: Future → mozilla0.9
|
|
Assignee | |
Comment 6•25 years ago
|
||
On further looking into this I'm willing to special case this since it looks
like of the keys that 4.x could even recognize, return and backspace are the
only two which are throwing their values as keycodes instead of charcodes
(thereby causing the value of event.which to be 0 for keypresses).
Changing milestone.
|
||
Comment 8•25 years ago
|
||
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
|
|
Assignee | |
Comment 10•25 years ago
|
||
|
|
Assignee | |
Comment 11•25 years ago
|
||
sr = jst
|
|
Assignee | |
Comment 12•25 years ago
|
||
r = peterv
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
||
Comment 14•24 years ago
|
||
verified fixed on 2001-08-06-09trunk -- windows 2000
Status: RESOLVED → VERIFIED
|
|
||
Comment 15•24 years ago
|
||
verified on build 2001-08-06-trunk
|
||
Updated•7 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•