Bug 35170

Summary: [Gtk] DOM listeners get wrong keycodes for some keys
Product: WebKit Reporter: Grant Gayed <grant_gayed>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, eric, mrobinson, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
Patch for this issue none

Description Grant Gayed 2010-02-19 13:13:24 PST
- observed with WebKitGTK 1.1.21

- view the html page at the bottom, which just prints key event keyCode values
- with NumLock OFF, note that pressing '0' or '.' on the keypad give events with keyCode == 0
  -> I think these should be 45 and 46 respectively
- press Shift+PrintScreen
  -> the resulting event's keyCode is 42, but it seems like it should be 44 (comparing with IE and Mozilla)

<html>
<head>
<script language="JavaScript">
function keyhandler(e) {
  alert(e.type);
  alert(e.keyCode);
}
function init() {
  document.onkeydown = keyhandler;
  document.onkeypress = keyhandler;
  document.onkeyup = keyhandler;
}
</script>
</head>
<body onLoad="init()">
<textarea rows="2" cols="20">
</textarea>
</body>
</html>
Comment 1 Alexey Proskuryakov 2010-03-28 13:31:55 PDT
Yes, 42 is VK_PRINT, and 44 is VK_SNAPSHOT, which is documented to be PRINT SCREEN.
Comment 2 Martin Robinson 2010-07-30 12:16:43 PDT
Created attachment 63092 [details]
Patch for this issue
Comment 3 Xan Lopez 2010-08-01 11:40:00 PDT
Comment on attachment 63092 [details]
Patch for this issue

Looks good to me.
Comment 4 Martin Robinson 2010-08-02 10:07:42 PDT
Comment on attachment 63092 [details]
Patch for this issue

Clearing flags on attachment: 63092

Committed r64470: <http://trac.webkit.org/changeset/64470>
Comment 5 Martin Robinson 2010-08-02 10:07:47 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 WebKit Review Bot 2010-08-02 10:27:42 PDT
http://trac.webkit.org/changeset/64470 might have broken Qt Linux Release
Comment 8 Martin Robinson 2010-08-03 08:56:24 PDT
Thanks for the heads up. I've fixed the expected results and posted a patch for this issue here: https://bugs.webkit.org/show_bug.cgi?id=43422