WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
28409
[Win] keypress should be dispatched for ctrl shortcuts
https://bugs.webkit.org/show_bug.cgi?id=28409
Summary
[Win] keypress should be dispatched for ctrl shortcuts
Julie Parent
Reported
2009-08-17 15:00:06 PDT
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.
Attachments
Test case
(667 bytes, text/html)
2009-08-17 15:00 PDT
,
Julie Parent
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Julie Parent
Comment 1
2009-08-17 18:53:07 PDT
+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?
Alexey Proskuryakov
Comment 2
2009-08-17 19:41:47 PDT
Why should WebKit dispatch keypress when no characters are tyoed? Per comments in Chromium bug, we match IE here. The bug is on Mac.
John Day-Richter
Comment 3
2009-10-01 14:29:14 PDT
(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/
Alexey Proskuryakov
Comment 4
2009-10-01 16:28:41 PDT
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.
Erik Arvidsson
Comment 5
2009-10-15 16:18:20 PDT
Updating summary to reflect the desired behavior
Erik Arvidsson
Comment 6
2009-10-21 16:00:47 PDT
Sorry for the premature conclusions. I've spent more time investigating this and we SHOULD fire keypress events when ctrl is pressed.
Alexey Proskuryakov
Comment 7
2009-10-21 16:16:21 PDT
Could you please post the investigation results here?
Erik Arvidsson
Comment 8
2009-10-21 17:03:17 PDT
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}
Alexey Proskuryakov
Comment 9
2010-02-09 20:37:34 PST
***
Bug 34767
has been marked as a duplicate of this bug. ***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug