On Windows, pressing Ctrl+[some keys] only fires the keyup event. Pressing Ctrl +[some other keys] does not fire any JavaScript key events at all. Here's how it breaks down: Ctrl+<key> only fires keyup: A,C,E,G,J,R,V,X,Z,0,-,=,insert Ctrl+<key> fires no events: D,F,K,L,M,N,O,P,Q,T,W Note that if a key is on either list, you can't use preventDefault (or an onkeypress/onkeydown handler that returns false) to override its default behavior.
same issue happened. i also confirm it.
<rdar://problem/5497037>
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.
Here's the output of the attached test case when using the accelerator combo for copy (cmd-c on mac, ctrl-c on windows) Safari 3 beta (3.0.4), Mac: * keyDown: U+0043, 67 * keyPress: U+0043, 99 Firefox 2, Mac: * keyDown: undefined, 224 * keyDown: undefined, 67 * keyPress: undefined, 0 * keyUp: undefined, 67 * keyUp: undefined, 224 Firefox 3 alpha (3.0a6), Mac: * keyDown: undefined, 224 * keyUp: undefined, 224 Opera 9.5 alpha (4404), Mac: * keyDown: undefined, 17 * keyPress: undefined, 17 * keyDown: undefined, 67 * keyPress: undefined, 99 * keyUp: undefined, 67 * keyUp: undefined, 17 Internet Explorer 7, Win (obviously :D): * keyDown: undefined, 17 * keyDown: undefined, 67 * keyUp: undefined, 67 * keyUp: undefined, 17 Firefox 2, Win: * keyDown: undefined, 17 * keyDown: undefined, 67 * keyPress: undefined, 0 * keyUp: undefined, 67 * keyUp: undefined, 17 Firefox 3 (3.0a6), Win -- identical to firefox 2, win. Opera 9.5 alpha (9500): * keyDown: undefined, 17 * keyPress: undefined, 17 * keyDown: undefined, 67 * keyPress: undefined, 67 * keyUp: undefined, 67 * keyUp: undefined, 17
Created attachment 16380 [details] Simple test case And of course WebKit/Win currently doesn't send any accelerators :-/
BTW, in a perfect world I'd still be able to block everything except Ctrl-W and Ctrl-Q. Since you're looking at the behavior of other browsers, the keys I use at http://wmd-editor.com/demo work on every major browser except Konqueror and Safari/Win -- and they do include Cmd/Ctrl-K and L from the list of keys that change browser state.
Turns out that this problem is mostly within Safari, not WebKit. As such, I'm closing this bug as INVALID, and it will continue to be tracked in Radar. Thank you for reporting this, and for providing insightful comments!