The default bug view has changed. See this FAQ.

nsEventStateManager re-dispatches NS_KEY_DOWN events as NS_KEY_PRESS events

VERIFIED FIXED in M7

Status

()

Core
Event Handling
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: tague, Assigned: tague)

Tracking

Trunk
All
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

18 years ago
In the current event architecture, nsEventStateManager re-dispatches NS_KEY_DOWN
events as NS_KEY_PRESS on the NS_KEY_DOWN handler.  NS_KEY_PRESS and NS_KEY_DOWN
can'be be mixed (this is part of the cause for #6896; the virtual keycode for
delete is the same as the character code for period, so when the period event
gets redispatched, it's interpreted as a delete)
(Assignee)

Updated

18 years ago
Blocks: 6896
(Assignee)

Updated

18 years ago
Blocks: 7470

Comment 1

18 years ago
The reason that the nsEventStateManager re-dispatches the NS_KEY_DOWN event has
been because the front end does not dispatch NS_KEY_PRESSes at all.  The only
spot now that does it is inside tague's debug code.  The correct sequence of
event for pressing and releasing a key is

keydown
keypress
keyup

To achieve this at the moment, since the front end only sends NS_KEY_DOWN,
regardless of whether the key event was caused by a system keydown message or a
system character message, we create and dispatch an NS_KEY_PRESS event after
the NS_KEY_DOWN.

So if the front end wants to start sending the NS_KEY_DOWN and NS_KEY_PRESS in
the proper order I'll remove the re-dispatch.  Otherwise we need it.

On a secondary note, this really shouldn't be part of bug 6896 if the charcode
and keycode fields are being filled out separately.  We have one field for
charcodes and another for keycodes in the nsKeyEvent.  Why is one being put in
the other?
(Assignee)

Updated

18 years ago
Assignee: joki → tague
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M7
(Assignee)

Comment 2

18 years ago
Turned on fix today (6/13/99; 2:30pm).  Should be in Monday's verification
build.

Updated

18 years ago
Whiteboard: 6/18 awaiting developer response

Comment 3

18 years ago
tague, looks like a code level fix.  Is there any way for me to verify this?
Thanks.
(Assignee)

Comment 4

18 years ago
i think you can just close it out as verified.  this is part of the big
uber-keyboard bug. if typing works correctly in the editor and the other bugs
have been verified, this got verified in the process.

Updated

18 years ago
Status: RESOLVED → VERIFIED
Whiteboard: 6/18 awaiting developer response

Comment 5

18 years ago
Thanks tague,
Marking Verified.
You need to log in before you can comment on or make changes to this bug.