7629 - nsEventStateManager re-dispatches NS_KEY_DOWN events as NS_KEY_PRESS events

Status: VERIFIED FIXED

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

Description

[tague]

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)

Comment 1

[joki (gone)]

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?

Comment 2

[tague]

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

Comment 3

[Jan Carpenter]

tague, looks like a code level fix.  Is there any way for me to verify this?
Thanks.

Comment 4

[tague]

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.

Comment 5

[Jan Carpenter]

Thanks tague,
Marking Verified.