[Webkit-unassigned] [Bug 14104] Win32: Ctrl+key fires keyup, but not keydown or keypress

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14104


oliver at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oliver at apple.com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1




------- Comment #3 from oliver at apple.com  2007-09-24 21:25 PDT -------
Righto, the problem is fairly simple, although the solution is non-trivial.

CWnd::PreTranslateMessage is being called prior to the key events being passed
into the WebView, this results in ::TranslateAccelerator being called and
converting the key events into commands, causing the key events to *never*
reach the webview, so there is never a JS event.

The events that never fire keyup are those events that change state in a way
that means the key up makes no sense:
D: brings up bookmarks, so changes focus target
F: find, changing focus target
K: changes focus target
L: goes to the location bar, changing focus target
M: minimises, thus changing focus target
N: new window, so changing focus target
O:open dialog, changed focus
P:print dialog, so changes focus
Q:quits -- clearly there can't be an keyup
T:new tabs, changes focus
W:closes tab, clearly can't send a keyup

The fix really needs to be to put off handling of the accelerators until after
the keydown or keypress has occurred.  As yet I haven't studied the other major
browsers in sufficient detail to determine when they actually handle the
accelerators, but i suspect it is after the keydown event has been fired and
before the keypress event.

This will require a platform specific handler in WebCore::EventHandler,
probably bool WebCore::EventHandler::handleCommandKeys(const
PlatformKeyEvent&), or similar.  This reordering should also allow us to
prevent key combos like cmd-w/q from being blocked by the DOM, which is just
silly.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.