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)
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?
Turned on fix today (6/13/99; 2:30pm). Should be in Monday's verification build.
tague, looks like a code level fix. Is there any way for me to verify this? Thanks.
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.
Status: RESOLVED → VERIFIED
Whiteboard: 6/18 awaiting developer response
Thanks tague, Marking Verified.
You need to log in before you can comment on or make changes to this bug.