Bug 25147

Summary: REGRESSION(r41760-41844): ESC Key does not fire document.onkeypress (affects Yahoo Mail)
Product: WebKit Reporter: Joseph Pecoraro <joepeck>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Major CC: ap, darin, dglazkov, glenn, jasneet, jon, kyle
Priority: P1 Keywords: Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
URL: http://bogojoker.com/webkit/keypress_test.html
Attachments:
Description Flags
Test page to easily display keypress/down/up charcodes. none

Joseph Pecoraro
Reported 2009-04-11 19:51:01 PDT
The ESC Key does not register the onkeypress function in the Webkit Nightly. It does in the Safari 4 beta, and previous versions of Safari. This is a regression error. Steps to reproduce: 1. Load the attached test file, or just go to the following URL with the test page: http://bogojoker.com/webkit/keypress_test.html Javascript is set to show the keypress, keydown, and keyup events in textareas and the console for both Webkit and Firefox (so you can easily compare). 2. Press any key you want. Observe that ESC does not show up in the Webkit Nightly. It does in Safari 4 beta (correctly as 27). Firefox's output is often 0 for keypress, but correct for ESC because it is a "non-character key."
Attachments
Test page to easily display keypress/down/up charcodes. (2.36 KB, text/html)
2009-04-11 19:52 PDT, Joseph Pecoraro
no flags
Joseph Pecoraro
Comment 1 2009-04-11 19:52:10 PDT
Created attachment 29418 [details] Test page to easily display keypress/down/up charcodes.
Joseph Pecoraro
Comment 2 2009-04-11 20:01:13 PDT
On Mac OS X: Safari 4 properly shows 27. Firefox 3.0.8 properly shows 27. Webkit Nightly does not show anything for ESC. On my Windows XP Virtual Machine: Chrome does not show anything for ESC. Firefox 2 properly shows 27.
Joseph Pecoraro
Comment 3 2009-04-12 07:47:06 PDT
Eek. Probably a duplicate of: [25012] and [18157] I must have overlooked those when I first searched.
Alexey Proskuryakov
Comment 4 2009-04-13 02:12:15 PDT
Wow. This is not quite a duplicate - the old bugs were not regressions! The difference is about what target the handler is installed on.
Alexey Proskuryakov
Comment 5 2009-04-13 03:11:04 PDT
*** Bug 25012 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 6 2009-04-13 06:42:49 PDT
Note that this is only a regression on Mac - on Windows, we didn't fire this event in Safari 3.2.1 either. This was probably caused by <http://trac.webkit.org/projects/webkit/changeset/41793> and related changes to _interceptEditingKeyEvent. This method now correctly discovers that the keydown event was handled, preventing keypress dispatch.
Glenn Maynard
Comment 7 2011-04-07 19:26:15 PDT
Please fix this. It breaks detection of keyboard autorepeat for these keys, which works in Firefox, Opera and IE. This isn't a Mac-specific issue.
Alexey Proskuryakov
Comment 8 2011-04-07 19:53:44 PDT
Could you please elaborate why detecting autorepeat for ESC matters, and how keypress helps with that? We should just implement KeyboardEvent.repeat attribute from DOM 3 Events spec (which obviously needs to be tracked in a different bug).
Glenn Maynard
Comment 9 2011-04-07 20:23:25 PDT
I forgot that keydown is fired on repeats--which doesn't make sense for the event name, but it gives a workaround here. I need to detect repeats on backspace, not escape, to detect changes to text input fields. But a correction: IE *doesn't* do this, which I'm guessing is the behavior WebKit's matching. Since there's no consistency here anyway, I guess fixing this won't really make much difference. (KeyboardEvent.repeat would be helpful, though unrelated--scripts having to track pressed keys manually is brittle.)
Alexey Proskuryakov
Comment 10 2014-03-10 09:52:29 PDT
Note You need to log in before you can comment on or make changes to this bug.