New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 33 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug-Regression

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
link

Issue 13891: Keypress event should fire for Ctrl+key combinations on Windows

Reported by ajpe...@gmail.com, Jun 11 2009

Issue description

Chrome Version       : 2.0.172.30, 3.0.183.1
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
     Safari 4: OK
     WebKit Nightly: OK

What steps will reproduce the problem?
1. Load the attached keypressexample.html into a problematic version of Chrome.
2. Click into the window to make sure it has focus.
3. Type Ctrl+c, (or Ctrl+a or Ctrl+v)

What is the expected result?

Chrome 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)

What happens instead?

Only keydown is fired.

Please provide any additional information below. Attach a screenshot if
possible.

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 keyboard shortcut like copy, paste, etc.
 
keypressexample.html
667 bytes View Download

Comment 1 by arv@chromium.org, Jun 11 2009

Labels: -Area-Misc Area-WebKit
Status: Available

Comment 2 by ojan@chromium.org, Jun 11 2009

Comment 3 by jon@chromium.org, Jul 20 2009

Labels: Mstone-3 ReleaseBlock-Stable Regression
We would not want to ship 3.0 with this bug.  Who is working on it?

Comment 4 by eseidel@chromium.org, Jul 30 2009

So this is Windows-only, and does not reproduce in Safari?  Am I reading that correctly?  
I cannot reproduce the bug as described in Safari 4 on the Mac or Chrome 3.0.195.1 on 
the Mac.

Comment 5 by ajpe...@gmail.com, Jul 30 2009

I only tested Chrome Windows, It didn't reproduce in Mac Safari or Windows Chrome 1.

Comment 6 by lafo...@chromium.org, Jul 30 2009

Labels: -Pri-2 -Area-WebKit Pri-1 Area-BrowserUI

Comment 7 by mal.chro...@gmail.com, Aug 3 2009

Labels: BugReview

Comment 8 by mal.chro...@gmail.com, Aug 3 2009

Status: Untriaged
I believe this is a webkit issue. It needs an owner. 

It's not clear whether missing this event affects any web sites.

Comment 9 by jon@chromium.org, Aug 3 2009

Labels: -Area-BrowserUI -BugReview Area-WebKit
Status: Assigned

Comment 10 by dglazkov@chromium.org, Aug 3 2009

Julie, can you look into this?

Comment 12 by Deleted ...@, Aug 6 2009

Comment 13 by brianh.s...@gmail.com, Aug 10 2009

In response to comment 8, this bug is affecting my company's web site. We provide
copy/paste via ctrl+c and ctrl+v in our app, and we rely on getting these keystroke
events. This functionality is confirmed broken in Chrome 2.0.172.39. It had worked in
Chrome in the past.

We were seeing that these shortcuts were broken in Safari 4 in early June, but they
were working again as of early August. I'm afraid I can't provide the specific
versions of Safari where we noticed the problem and found that it had been fixed.

Comment 14 by gwilson@chromium.org, Aug 13 2009

Hi Julie, any progress on this?  (Is it a webkit issue, or a glue issue?)

Comment 15 by jparent@chromium.org, Aug 13 2009

I'll get to this in more detail tomorrow, but I'm pretty sure it is a glue issue, since 
it doesn't reproduce in WebKit nightlies.

Comment 16 by jparent@chromium.org, Aug 14 2009

It isn't all browser shortcuts causing this.

For example, control + c, control + x, control + v, control + a, control + b, control + 
i do not generate a keypress event, but control + f (find in page), control + s (save), 
control + p (print) do.  My first guess is that only editing events are not generating 
the keypress.  Investigating more.

Comment 17 by jpar...@gmail.com, Aug 15 2009

Andy, when you said this didn't repro in WebKit nightlies or Safari, were you referring 
to Windows or Mac or both?

This repros for me in the latest WebKit nightly on Windows and Safari 4.0.2 on Windows.  
Thus, this is definitely a WebKit bug.

Comment 18 by ajpe...@gmail.com, Aug 15 2009

Hmm. It's been a while but I believe I tested Safari 3, 4, and WebKit nightly on Mac
OS X, and Chrome on Windows. No Safari on Windows or Chrome on Mac tests.

Comment 19 by faiv...@gmail.com, Aug 17 2009

As noted here: http://extjs.com/forum/showthread.php?t=46144
Chrome (3.0.197.11) on Windows does not fire the right Ctrl-Enter keycode.
(Works on linux)

Is it related ?

Comment 20 by faiv...@gmail.com, Aug 17 2009

Well maybe not.
Simply not implemented yet I think.
http://blog.brothersoft.com/2009/07/22/google-chrome-301951-released/

Changes for Linux:
•	Add additional hotkeys (Ctrl-Enter, Shift-F5, Shift + Scroll Wheel).

Comment 21 by makapoh....@gmail.com, Aug 17 2009

Chromium 3.0.190.2

not work Ctrl + C, Ctrl + V when keyboard in Russian Layout
when set english all works fine..

Comment 22 by Deleted ...@, Aug 17 2009

Comment 23 by jparent@chromium.org, Aug 17 2009

FYI, IE does not fire keypress for any of these cases, only Firefox and old WebKit and 
WebKit on Mac do.

Filed WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=28409

Comment 24 by jon@chromium.org, Aug 19 2009

Labels: mstone4
Moving these from milestone 3 to milestone 4 because we would not block 
the release for these bugs.  However, they are important and work should 
continue.  If we get a fix for these we would consider patching the stable 
release.

Comment 25 by jon@chromium.org, Aug 19 2009

Labels: -mstone4 Mstone-4

Comment 26 by martin.w...@gmail.com, Sep 7 2009

I have tested this on OSX (10.5.8) with Chrome 4.0.206.1 and its the same problem. But 
its even worse using the cmd key. After pressing the cmd key, not even the keyDown 
event will be fired. Checked it also on Safari 4.0.3 and Webkit nightlies and both of them 
fire the missing two events.

Comment 27 by johndayrichter@google.com, Oct 1 2009

I've done some detailed study of this bug (it is now a major pain point on my current
project) and I'm convinced that it is a webkit issue, since every webkit browser I've
looked at exhibits some version of this behavior. But every browser I tried has
subtle differences.

On Chrome for Windows, every Ctrl+<letterkey> combination fires KEYDOWN, KEYPRESS,
KEYUP except:

Ctrl+A
Ctrl+C
Ctrl+H
Ctrl+V
Ctrl+W
Ctrl+X

All Ctrl+Shift+letterkey combinations fire KEYDOWN, KEYPRESS, KEYUP.

I'm sure this is at least partially a consequence of Webkit internals (since Safari
for Windows has similar behavior with different keys - on Safari most ctrl+key
combinations DON'T fire KEYPRESS, but Ctrl+B, Ctrl+X and others do)

It doesn't much matter to us whether Chrome decides to fire a keypress with these
events or not, but we would very much like every Ctrl+key combination to behave in
the same way.

(Note: I'm posting some of this information in the webkit bug as well)

Comment 28 by johndayrichter@google.com, Oct 1 2009

I mistyped in my last post when describing Safari behavior - Ctrl+X doesn't fire a
keypress in Windows Safari. Ctrl+K does not fire a keypress in Safari, but it does in
Chrome.

This difference may be accounted for by the fact that Ctrl+K is a browser hotkey in
both browsers, so the normal event sequence is interrupted. I cannot prevent the
default brower behavior without suppressing KEYPRESS events too.

Comment 29 by jparent@chromium.org, Oct 15 2009

Comment 30 by arv@chromium.org, Oct 15 2009

To sum up the current plan.

I intend to make sure that we never fire a keypress for a ctrl+key. We should only fire 
keydown and keyup for these.

Comment 31 by karen@chromium.org, Oct 15 2009

adding jeffrey so he can track the bug.

Comment 32 by lost.gob...@gmail.com, Oct 15 2009

Just to make sure if I understand what this bug is about: will the fix make it
impossible to 'override' the behavior of common shortcuts like Ctrl-W? I ask because
I wrote an extension to do precisely that (it implements the standard Unix-style text
editing shortcuts like ^U to delete to the start of line and ^W to delete previous
word), and this would break my extension.

Comment 33 by arv@chromium.org, Oct 15 2009

lost.goblin: You will still get keydown events for these.

Comment 34 by lost.gob...@gmail.com, Oct 15 2009

Yes, I understood that. I should have been more clear: will I be able to stop
propagation and prevent the default behavior from taking place? Part of the whole
point of the extension is to keep Ctrl-W from closing the window.

I'm currently using the keydown events, and stopping the propagation of those seems
to do the trick, but just wanted to make sure I understood this right (even after
writing the extension I still feel rather clueless about how JavaScript keyboard
events really work). BTW, in case anyone is interested in checking it out:
http://repo.cat-v.org/burning_chrome/hosaka/

Thanks again and sorry if I'm being excessively obtuse :)

Comment 35 by arv@chromium.org, Oct 15 2009

Comment 36 by arv@chromium.org, Oct 17 2009

Labels: -OS-All OS-Windows
Status: Started
Summary: Keypress event should not fire for Ctrl+key combinations on Windows
lost.gobling: event.preventDefault() works so you can prevent things like Ctrl+S (as in 
save). Preventing the default action in Ctrl+W does not prevent closing the window. I'm 
pretty sure we don't want to allow that but please file a new bug saying that you want 
to be able to do this in an extension.

Comment 37 by arv@chromium.org, Oct 20 2009

Summary: Keypress event should fire for Ctrl+key combinations on Windows
I'm changing this again. We should fire keypress events for ctrl+character since there 
is a lot of code out there that depends on this behavior.

Comment 38 by Deleted ...@, Oct 21 2009

Its affecting also the quick search launch of Google Desktop: Ctrl + Ctrl

Comment 39 by thakis@chromium.org, Oct 23 2009

If the keydown() for ctrl-key is cancelled, we shouldn't send keypress() though, right?

Comment 41 by hbono@chromium.org, Oct 28 2009

arv,

Even though I don't have any opinions about whether or not to send keypress events for 
ctlr+character, I'm a little interested in how to handle ctrl+charcter when we use NON-
ALPHABETICAL layouts, e.g. Russian, Hebrew, etc.

Regards,

Comment 42 by pkasting@chromium.org, Nov 6 2009

Can someone summarize clearly what our current behavior is?  It's not clear whether we 
have a behavior that is consistent across all shortcuts, across all shortcuts the 
browser handles, or across certain particular editing shortcuts.

It's also not clear how we compare to Safari/Mac versus Safari/Win versus Firefox and 
IE.

It's hard to say what is and is not broken when it's not clear what's going on.

Comment 43 by daniel.d...@gmail.com, Nov 7 2009

On Linux Chrome:

W,T,N -> No key event, not cancellable
ZXCVAUI -> keydown, no keypress
Others -> keypress, with a character code that is the letter number (A = 1, B = 2, ...)

Mac chrome is different. Haven't checked Windows Chrome.

http://www.danilatos.com/event-test/ExperimentTest.html

Comment 44 by arv@chromium.org, Nov 9 2009

Comment 45 by ericu@chromium.org, Dec 12 2009

I've logged http://code.google.com/p/chromium/issues/detail?id=30186 for lost.goblin's 
"let extensions prevent ctrl+w from closing the window" feature request.

It affects my extension too.

Comment 46 by brycesto...@gmail.com, Jan 27 2010

This should be triaged for Mstone-4.1 or Mstone-5.

Comment 47 by arv@chromium.org, Jan 27 2010

Status: Available
Unassigning since I don't have time to work on this any time soon.

Comment 48 by suzhe@chromium.org, Jan 27 2010

Is this issue still valid? According to  issue 5496 , things like ctrl-w, ctrl-t, ctrl-n 
will not be sent to the renderer at all. Other ctrl key bindings should work without 
any problem.

Comment 49 by bloom@google.com, Feb 1 2010

Some ctrl key bindings, such as Ctrl+S, are not mentioned in  issue 5496 , but still 
seem to not fire keypress events.

Comment 50 by suzhe@chromium.org, Feb 2 2010

If a key binding corresponds to a browser action, then if the key down event is not 
handled by the web page, it'll be handled by the browser to perform the corresponding 
action. In this case, the corresponding key press event will be suppressed to prevent 
the web page from handling it. Otherwise if the key press event is sent to the web 
page, another action may be triggered in the web page along with the browser action, 
which may confuse the user.

In this case, if the web page really wants to handle the key press event, it must 
prevent the default action of the corresponding key down event first by calling 
event.preventDefault(), then the browser will send the key press event to the web 
page rather than performing the corresponding browser action.

Some well known browser shortcut keys:
ctrl-s  save page
ctrl-l  focus location bar
ctrl-f  find in page
ctrl-g  find next in page
ctrl-r  reload
ctrl-o  open file
ctrl-p  print
...

Comment 51 by arv@chromium.org, Feb 9 2010

 Issue 35186  has been merged into this issue.

Comment 52 by jeffharris@google.com, Feb 10 2010

Just to confirm. The bug that was merged was specifically about Mac behavior. Is this 
bug covering both Mac and Windows behavior?

Comment 53 by ghuo@google.com, Apr 6 2010

Hello, any progress on this issue?

Comment 54 by karen@chromium.org, Apr 8 2010

Labels: -Mstone-4 Mstone-5
Status: Untriaged

Comment 55 by dglazkov@chromium.org, Apr 8 2010

Labels: -Mstone-5 Mstone-6
Status: Assigned

Comment 56 by ghuo@google.com, May 28 2010

Ping. Is ojan still the appropriate owner for this?

Comment 57 by jeffreyc@chromium.org, May 28 2010

Yep, he is. He is tackling this for Chrome mstone 6.0.

Comment 58 by suzhe@chromium.org, May 29 2010

Please let me know when you start to fix this issue.

Comment 59 by ojan@chromium.org, Jun 16 2010

Labels: -Pri-1 -Mstone-6 Pri-3 Mstone-X
Sorry, I just looked at this in detail for the first time. For the most part Chrome/WebKit matches IE here in that we don't fire keypress events for ctrl+key combinations. There are a few cases where IE does fire them and Chrome/WebKit doesn't and vice versa, but that seems pretty minor to me. Changing the priority and mstone accordingly.

There is an issue where Google's Closure library doesn't send WebKit down the IE codepath, but that's being fixed in Closure.

Also, keypress is deprecated in the latest DOM spec. Keydown is all the rage.

Comment 60 by lafo...@chromium.org, Jun 29 2010

Anything labeled mstone:x by definition is not a blocker for stable.

Comment 61 by kerz@chromium.org, Jul 7 2010

Labels: -ReleaseBlock-Stable

Comment 62 by harikris...@gmail.com, Sep 29 2010

Why this issue is not yet fixed since it is reported in the version of 2.0.172.30 and the current version is gone to 6. And not yet the milestone is decide.

It is an absolute blocker in my web site to provide shortcuts. Kindly fix this ASAP.

Comment 63 by suzhe@chromium.org, Sep 29 2010

Status: Available
Please refer to comment #50 for the reason. I think we should close this issue as WontFix.

Comment 64 by arv@chromium.org, Sep 29 2010

Status: WontFix
Yeah, this works as intended.

Use keydown for non generating keys.

Comment 65 by akarc...@gmail.com, Oct 18 2010

hi suzhe,

  NON stopable keyevent for "ctrl+n" in document.onkeydown, chrome windows version 6.0.472.63.

  I have go through all the comments in this issue, and it would be great if the keyevent for "ctrl+n" also in your comment #50 list.

  Are there any reason that some key combinations that browser are hijacking them and let the app developer helpless?

  btw, are you also the scim ime developer? :)

Comment 66 by suzhe@chromium.org, Oct 18 2010

Hi akarchen, for your question regarding to ctrl+n, please refer to  issue 5496 .

Comment 67 Deleted

Comment 68 by akarc...@gmail.com, Oct 27 2010

hi suzhe, i have posted a comment( http://code.google.com/p/chromium/issues/detail?id=5496#c57). my request should belong to that issue.
And now i am waiting for the feedback.

thank you

Comment 69 by akarc...@gmail.com, Nov 3 2010

may chromeplus.org is a solution? worth to try.

Comment 70 by donrhum...@gmail.com, Oct 20 2011

keypress still is not being fired if the ctrl key is held down in Chrome 14.0.835.202 on linux.

Comment 71 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 72 by bugdroid1@chromium.org, Mar 9 2013

Project Member
Labels: -Type-Bug -Regression Type-Bug-Regression

Comment 73 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-WebKit Cr-Content

Comment 74 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 75 by laforge@google.com, Jul 24 2013

Cc: -jeffreyc@google.com

Sign in to add a comment