Bug 25147

Summary: REGRESSION(r41760-41844): ESC Key does not fire document.onkeypress (affects Yahoo Mail)
Product: WebKit Reporter: Joseph Pecoraro <joepeck@webkit.org>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned@lists.webkit.org>
Status: RESOLVED FIXED    
Severity: Major CC: ap@webkit.org, darin@apple.com, dglazkov@chromium.org, glenn@zewt.org, jasneet@chromium.org, jon@chromium.org, kyle@geek.net
Priority: P1 Keywords: NeedsRadar, Regression
Version: 528+ (Nightly build)   
Hardware: Macintosh   
OS: Mac 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

Description From 2009-04-11 19:51:01 PST
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 From 2009-04-11 19:52:10 PST -------
Created an attachment (id=29418) [details]
Test page to easily display keypress/down/up charcodes.
------- Comment #2 From 2009-04-11 20:01:13 PST -------
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 From 2009-04-12 07:47:06 PST -------
Eek.  Probably a duplicate of:
[25012] and [18157]

I must have overlooked those when I first searched.
------- Comment #4 From 2009-04-13 02:12:15 PST -------
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 From 2009-04-13 03:11:04 PST -------
*** Bug 25012 has been marked as a duplicate of this bug. ***
------- Comment #6 From 2009-04-13 06:42:49 PST -------
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 From 2011-04-07 19:26:15 PST -------
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 From 2011-04-07 19:53:44 PST -------
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 From 2011-04-07 20:23:25 PST -------
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 From 2014-03-10 09:52:29 PST -------
This was fixed in <http://trac.webkit.org/changeset/165356>.