14104 2007-06-12 15:39:04 -0700 Win32: Ctrl+key fires keyup, but not keydown or keypress 2007-12-21 12:27:24 -0800 1 1 1 Unclassified WebKit New Bugs 523.x (Safari 3) PC Windows XP RESOLVED INVALID http://unixpapa.com/js/testkey.html InRadar, PlatformOnly P2 Normal --- 1 john webkit-unassigned ap heatherita oliver sysadmin vicki oldest_to_newest 7751 0 john 2007-06-12 15:39:04 -0700 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. 218 1 sysadmin 2007-09-21 02:43:39 -0700 same issue happened. i also confirm it. 201 2 ddkilzer 2007-09-21 06:25:10 -0700 <rdar://problem/5497037> 26 3 oliver 2007-09-24 21:25:38 -0700 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. 20 4 oliver 2007-09-24 22:20:39 -0700 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 21 5 16380 oliver 2007-09-24 22:22:17 -0700 Created attachment 16380 Simple test case And of course WebKit/Win currently doesn't send any accelerators :-/ 63172 6 john 2007-12-03 13:01:13 -0800 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. 64978 7 ap 2007-12-21 12:27:24 -0800 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! 16380 2007-09-24 22:22:17 -0700 2007-09-24 22:22:17 -0700 Simple test case keyTest.html text/html 477 oliver PGlucHV0IHR5cGU9InRleHQiIG9ua2V5ZG93bj0ibG9nKCdrZXlEb3duOiAnICsgZXZlbnQua2V5 SWRlbnRpZmllciArJywgJyArIGV2ZW50LmtleUNvZGUpOyIgb25rZXlwcmVzcz0ibG9nKCdrZXlQ cmVzczogJyArIGV2ZW50LmtleUlkZW50aWZpZXIgKycsICcgKyBldmVudC5rZXlDb2RlKSIgb25r ZXl1cD0ibG9nKCdrZXlVcDogJyArIGV2ZW50LmtleUlkZW50aWZpZXIgKycsICcgK2V2ZW50Lmtl eUNvZGUpIj4KPHVsIGlkPSJjb25zb2xlIj4KPC91bD4KPHNjcmlwdD4KZnVuY3Rpb24gbG9nKHN0 cikgewogICAgdmFyIGNvbnNvbGUgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiY29uc29sZSIp OwogICAgdmFyIGxpID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgibGkiKTsKICAgIGxpLmFwcGVu ZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKHN0cikpOwogICAgY29uc29sZS5hcHBlbmRD aGlsZChsaSk7Cn0KPC9zY3JpcHQ+