Bug 25147 - REGRESSION(r41760-41844): ESC Key does not fire document.onkeypress (affects Yahoo Mail)
Summary: REGRESSION(r41760-41844): ESC Key does not fire document.onkeypress (affects ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Major
Assignee: Nobody
URL: http://bogojoker.com/webkit/keypress_...
Keywords: Regression
: 25012 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-11 19:51 PDT by Joseph Pecoraro
Modified: 2014-03-10 09:52 PDT (History)
7 users (show)

See Also:


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 Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Pecoraro 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."
Comment 1 Joseph Pecoraro 2009-04-11 19:52:10 PDT
Created attachment 29418 [details]
Test page to easily display keypress/down/up charcodes.
Comment 2 Joseph Pecoraro 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.
Comment 3 Joseph Pecoraro 2009-04-12 07:47:06 PDT
Eek.  Probably a duplicate of:
[25012] and [18157]

I must have overlooked those when I first searched.
Comment 4 Alexey Proskuryakov 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.
Comment 5 Alexey Proskuryakov 2009-04-13 03:11:04 PDT
*** Bug 25012 has been marked as a duplicate of this bug. ***
Comment 6 Alexey Proskuryakov 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.
Comment 7 Glenn Maynard 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.
Comment 8 Alexey Proskuryakov 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).
Comment 9 Glenn Maynard 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.)
Comment 10 Alexey Proskuryakov 2014-03-10 09:52:29 PDT
This was fixed in <http://trac.webkit.org/changeset/165356>.