Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 25249 Send keypress() events in addition to keydown() events for ctrl-key on OS X.
Starred by 6 users Project Member Reported by tha...@chromium.org, Oct 19, 2009 Back to list
Status: Verified
Owner: tha...@chromium.org
Closed: Nov 2009
Cc: a...@chromium.org, jparent@chromium.org, jam@chromium.org, jeremy@chromium.org, hbono@chromium.org, suzhe@chromium.org, arv@chromium.org
OS: Mac
Pri: 1
Type: Bug
M-4

Blocking:
issue 15090

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
What steps will reproduce the problem?
1. Go to docs
2. Hit ctrl-1

What is the expected result?

Current line should become a H1.

What happens instead?

Nothing.
 
Comment 1 by evan@chromium.org, Oct 19, 2009
Comment 2 by tha...@chromium.org, Oct 19, 2009
Looks like we only send keydowns and keyups for ctrl and 1, while Safari additionally 
sends a keypress for ctrl-1.

Comment 3 by tha...@chromium.org, Oct 19, 2009
Hm, but chrome/linux seems to only send keydown and keyup, and it works over there, 
so maybe that's not the cause.
Comment 4 by tha...@chromium.org, Oct 19, 2009
…but the keycode for the ctrl keydown is 0 on mac, while it's 17 on linux.
Comment 5 by tha...@chromium.org, Oct 20, 2009
Actually, that's a lie, our keycode is 17 too. At the moment, my theory is that docs sees 
that os == mac and hence expects a keypress which we don't send (and which docs 
doens't expect on linux).
Comment 6 by tha...@chromium.org, Oct 20, 2009
Status: Started
There is a horrible fix at http://codereview.chromium.org/293019 that effectively sends 
a keypressed() in addition to the keydown(), but maybe this is a docs bug (it does work 
with the current events on linux after all). I need to talk to the docs guys and read up on 
how keyboard stuff is supposed to work.

CC'd people, maybe this is interesting to you.
Comment 7 by tha...@chromium.org, Oct 20, 2009
Comment 8 by tha...@chromium.org, Oct 20, 2009
From the CL comments: http://www.quirksmode.org/dom/events/keys.html suggests 
that non-visible keyboard entries such as ctrl-1 shouldn't fire keypress() events.
Comment 9 by arv@chromium.org, Oct 20, 2009
Key events fell through all the standardization process for a very long time. Key 
events are back on track but the current proposal, http://www.w3.org/TR/DOM-Level-3-
Events/#event-type-keypress , deprecates keypress events instead of dealing with the 
browser incompatibility mess.

Here is a mail sent to webkit-dev when Apple changed the key events in Safari to match 
IE better: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg01555.html.

Note that what PPK says makes sense in a perfect world and it is the only sane behavior 
but almost nothing is sane when it comes to key events and WebKit is trying to follow 
IE in spirit but have a few Gecko-ism for compatibility.
Comment 10 by tha...@chromium.org, Oct 21, 2009
One thing that is not trivial to do is making the keypress() events cancellable. RIght now 
we trigger accelerators on the keydown()'s ACK message – and doing it on the 
keypress() ACK doesn't work on OS X, because Cocoa can't fire menu items based on 
the synthetic events we create for keypress()s.

One way that might work would be to keep a map from keydown() to keypress() events 
in the browser process and send the keydown() event back to cocoa once the keypress() 
ACK arrives. I suspect this will be annoying on windows and linux as well.
Comment 11 by arv@chromium.org, Oct 21, 2009
It seems Safari Mac allows you to prevent Command+T in keypress
Comment 12 by tha...@chromium.org, Oct 21, 2009
Yes, Safari makes nearly all shortcuts cancelable (there are some that are not cancelable, 
e.g. cmd-1, but nearly all of them are)
Comment 13 by arv@chromium.org, Oct 22, 2009
On Mac we need to fire repeating keypress events for all keyboard events unless we are 
in an editable field and ctrl+key is an emacs command.
Comment 14 by arv@chromium.org, Oct 22, 2009
To clarify:

"all keyboard events" means all keys that would have generated keypress without 
ctrl/meta. So, ctrl+a should fire a keypress event, meta+a should fire a keypress event 
but ctrl+up arrow should not.
Comment 15 by hbono@chromium.org, Oct 26, 2009
thakis,

(in reply to comment 12)

> Yes, Safari makes nearly all shortcuts cancelable (there are some that are not cancelable, e.g. cmd-1, but nearly all of them are)

It seems there are some issues about our key-event handling code and preventDefault(), e.g. Issue 15311, Issue 23824, etc.

Regards,
Comment 16 by tha...@chromium.org, Oct 26, 2009
Summary: Send keypress() events in addition to keydown() events for ctrl-key on OS X. (was: NULL)
Previous summary was "Ctrl-1 doesn't make text a heading in docs", but this bug is 
really about the more general "we should be more like Safari on OS X". See the thread on 
chromium-dev.
Comment 17 by tha...@chromium.org, Oct 30, 2009
Labels: -Pri-2 Pri-1 Mstone-4 ReleaseBlock-Beta
Given that this affects web compat, I'm increasing the priority on this. I hope to have the 
fix ready over the weekend.
http://codereview.chromium.org/293019 now contains what I think we should do.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31287 

------------------------------------------------------------------------
r31287 | thakis@chromium.org | 2009-11-06 12:34:24 -0800 (Fri, 06 Nov 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=31287&r2=31286
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=31287&r2=31286

Send keypress() events for ctrl-key and cmd-key in addition to keydown().

The ctrl-key behavior matches what Safari does: We first send a keydown for ctrl-key, and only if the key is not an emacs shortcut, we send a keypress.

The cmd-key behavior is slightly different from Safari: Safari triggers menu items after the keypress command has not been swallowed by javascript. We trigger menu items after keydown. That means that if the user hits cmd-key, we send a keydown and only send a keypress if the shortcut doesn't trigger a menu item. Safari always sends both keydown and keypress.

BUG= 25249 
TEST=Go to http://unixpapa.com/js/testkey.html . Hit ctrl-a, only a keydown should be generated. Hit ctrl-s, both keydown and keypress should be generated. Hit cmd-a, only a keydown should be generated. Hit cmd-shift-a, both keypress and keydown should be generated. Also, ctrl-1 now makes something a heading in google docs. Cmd-s and Cmd-f should still work in docs.

Review URL: http://codereview.chromium.org/293019
------------------------------------------------------------------------

Status: Fixed
Comment 21 by ismail@chromium.org, Nov 12, 2009
Status: Verified
Ctrl+1 --> turns the line to H1 on docs.

Platform:
  Hostname: testings-macbook-pro-15.local
  Mac OS X Version 10.6.1 (Build 10B504)
  Processor: 2 Intel 2.33 GHz
  RAM: 2048 MB

Chrome:
  Chrome version: 4.0.245.0 r31763  <<<Release>>>
  QuickTime Player: <unknown>
  QuickTime PlayerX: 51
  Flash Player: 10.0.32

Comment 22 by bugdro...@gmail.com, Nov 18, 2009
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31287 

------------------------------------------------------------------------
r31287 | thakis@chromium.org | 2009-11-06 12:34:24 -0800 (Fri, 06 Nov 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=31287&r2=31286
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=31287&r2=31286

Send keypress() events for ctrl-key and cmd-key in addition to keydown().

The ctrl-key behavior matches what Safari does: We first send a keydown for ctrl-key, and only if the key is not an emacs shortcut, we send a keypress.

The cmd-key behavior is slightly different from Safari: Safari triggers menu items after the keypress command has not been swallowed by javascript. We trigger menu items after keydown. That means that if the user hits cmd-key, we send a keydown and only send a keypress if the shortcut doesn't trigger a menu item. Safari always sends both keydown and keypress.

BUG= 25249 
TEST=Go to http://unixpapa.com/js/testkey.html . Hit ctrl-a, only a keydown should be generated. Hit ctrl-s, both keydown and keypress should be generated. Hit cmd-a, only a keydown should be generated. Hit cmd-shift-a, both keypress and keydown should be generated. Also, ctrl-1 now makes something a heading in google docs. Cmd-s and Cmd-f should still work in docs.

Review URL: http://codereview.chromium.org/293019
------------------------------------------------------------------------

Project Member Comment 23 by bugdroid1@chromium.org, Oct 12, 2012
Blocking: -chromium:15090 chromium:15090
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.
Project Member Comment 24 by bugdroid1@chromium.org, Mar 10, 2013
Labels: -Mstone-4 M-4
Project Member Comment 25 by bugdroid1@chromium.org, Mar 13, 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment