The Viewer application's event look (nsWinMain.cpp, nsNativeViewerApp::Run()) handles Window's messages incorrectly. Viewer tries to handle keyboard events prior to calling TranslateMessage, this prevents Input Methods from ever seeing any keyboard events and sending the appropriate Messages to the application. Input Methods have to have a chance at keyboard events (by calling TranslateMessage) prior to all other keyboard processing.
Assignee: rickg → joki
Component: Viewer App → Event Handling
Priority: P3 → P1
Target Milestone: M3
Putting on M3 radar whilst eng checks this out. Moving to Events Handling component.
Setting QA Contact to janc
Tom :- Per our hallway conversations, If you don't consider this your bug, please comment and reassign. thanks.
Assignee: joki → rods
Summary: Viewer incorrectly processes Window's events → nsWindow.cpp incorrectly processes Window's events
(1) Changed Summary of Bug (2) changing owner from firstname.lastname@example.org to email@example.com per email from Peter Trudelle (3) More detailed information: The bug with keyboard event processing in in the Window's Message Handler, where it handles WM_KEYUP and WM_KEYDOWN events. Normally, in a windows application keyboard input is handled as WM_CHAR events or WM_IME_*COMPOSITION messages - depending on if inline input is supported or not. Right now the message handler for nsWindow.cpp is attempting to process key events on the WM_KEY* messages and convert them into character events. This prevents international keyboards and input methods from working correctly. When an input method is engaged, the WM_KEY* messages have to be given to the DefWindowProc, so that the operating system can translate them into input method messages. Because nsWindow.cpp traps the WM_KEY* events, input methods do not work properly. Please contact me if you need more information about fixing this bug.
Is this is really only a Viewer bug? If so, shouldn't it be reassigned to someone in Gecko?
This is not a viewer-only bug. Tague's early work was done on viewer because Ender wasn't incorporated into apprunner at that time. Tague is now doing his work on apprunner, but the bug still applies to apprunner. Didn't make it for M4. Need this for M5 ASAP.
Cross reference to related bug: http://bugzilla.mozilla.org/show_bug.cgi?id=3864
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
I didn't do anything with the IME code, but nsWindow (on Windows) is now handling the WM_CHAR event.
fixed as part of large keyboard whackage. marking verified.
You need to log in before you can comment on or make changes to this bug.