Closed Bug 3864 Opened 26 years ago Closed 25 years ago

backspaces/navigation keys handled improperly

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: tague, Assigned: joki)

Details

The current Seamonkey architecture tries to handle navigation keys as Virtual Keys (WM_KEYUP/WM_KEYDOWN) messages. This prevents input methods from ever seeing backspace events, so Japanese users can't correct their input. *ALL* key events, including Navigation events have to be handled after input methods have a chance at them - this means they have to be handled on the WM_CHAR event for Windows.
Target Milestone: M4
Priority: P3 → P1
Changed from P3 to P1. We need the keyboard events fixed ASAP because the Japanese input methods depend upon this.
Status: NEW → ASSIGNED
The WM_CHAR part of this is being fixed. Tague, still need you to get back to me on how to handle navigation keys which don't fire a WM_CHAR.
Check to see if it is handled by the default window proc - if it is, leave it alone, otherwise process to your hearts cotnent.
Target Milestone: M4 → M5
Okay. Unfortunately processing the event through the default proc *before* going to the content system is a pretty major change. We currently handle all events before default processing. I'm going to push this to M5 while we think about this.
Cross reference to related bug: http://bugzilla.mozilla.org/show_bug.cgi?id=3546
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Sorry, mistakenly closed.
Target Milestone: M5 → M6
Moving off M5 radar since Tom is out of town.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
fixed as part of the big keyboard whackage at least. marking 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.