Created attachment 34993 [details] Test case Windows only - keypress is dispatched properly for Mac. Reproduces in WebKit nightly, Safari 4.0.2, Chrome 3.*, Chrome 4.*. Did not reproduce in Chrome 1.* Repro steps: 1. Load the attached keypressexample.html. 2. Click into the window to make sure it has focus. 3. Type Ctrl+c, (or Ctrl+a or Ctrl+v) Expected result: WebKit should fire both a keydown and a keypress event. (These events will be logged to the screen by a script in the provided html page) Result: Only keydown is fired. For more details, see original bug filed against Chrome: http://code.google.com/p/chromium/issues/detail?id=13891 Note: This seems to happen for a subset of Ctrl+* key combinations. I haven't tried all of them, but it seems to happen only for ones where there is also an existing browser editing keyboard shortcut like copy, paste, etc.
+Adele, Darin, Alexey, who were all involved with similar issues on Mac (such as https://bugs.webkit.org/show_bug.cgi?id=25147). Any ideas?
Why should WebKit dispatch keypress when no characters are tyoed? Per comments in Chromium bug, we match IE here. The bug is on Mac.
(In reply to comment #2) > Why should WebKit dispatch keypress when no characters are tyoed? Per comments > in Chromium bug, we match IE here. The bug is on Mac. The problem is not that keypress events are not dispatched. The problem is that webkit browsers seem to dispatch the events inconsistently. Here's a sample of behaviors: Keystroke Chrome (Windows) Events Safari (Windows) Events Ctrl+A KEYDOWN, KEYUP KEYDOWN, KEYUP Ctrl+B KEYDOWN, KEYPRESS, KEYUP KEYDOWN, KEYPRESS, KEYUP Ctrl+X KEYDOWN, KEYUP KEYDOWN, KEYUP Ctrl+D KEYDOWN, KEYPRESS KEYDOWN In both browsers all Ctrl+Shift+key combinations generate a keypress. It doesn't much matter whether Webkit fires a keypress in these instances or not, but it would be very helpful if it had the same behavior for Ctrl+key combinations. These tests were done using the tool at http://people.w3.org/rishida/utils/keyevents/
Comment 3 definitely describes a bug, but that's not what was reported here. If we fix the inconsistency by never dispatching keypress for these shortcuts, claiming that the original bug is resolved as fixed would be inappropriate.
Updating summary to reflect the desired behavior
Sorry for the premature conclusions. I've spent more time investigating this and we SHOULD fire keypress events when ctrl is pressed.
Could you please post the investigation results here?
Internet Explorer does not fire keypress when ctrl is pressed with some exceptions. The following keys fire keypress. Some keys behave slightly different in editable elements. CTRL + | keyCode | contentEditable | textarea -------+---------+-----------------+--------- G | 7 | Y | Y M | 13 | Y | Y U | 21 | N | Y V | 22 | N | N X | 24 | N | N Y | 25 | N | N Z | 26 | N | N [ | 27 | Y | Y \ | 28 | Y | Y ] | 29 | Y | Y SPACE | 30 | Y | Y ENTER | 10 | Y | Y Safari Mac Always fires keypress when ctrl is pressed unless focus is in an editable element. The keyCode matches IE Safari Windows Never fires keypress when ctrl is pressed Firefox Windows Always fires keypress events. The main difference here is that Firefox returns the charCode of the key as if ctrl was not pressed. For example Ctrl+A returns A: {keyCode: 0, charCode: 97, ctrlKey: false} Ctrl+A: {keyCode: 0, charCode: 97, ctrlKey: true} For the keys on Safari Mac we get A: {keyCode: 97, charCode: 97, ctrlKey: false} Ctrl+A: {keyCode: 1, charCode: 1, ctrlKey: true}
*** Bug 34767 has been marked as a duplicate of this bug. ***