My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2606: Chrome doesn't work with "keypress" event and arrow keys.
16 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  ----
Closed:  Sep 2009
Cc:  dglazkov@chromium.org, o...@chromium.org, ka...@chromium.org

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by Barzz...@gmail.com, Sep 21, 2008
Product Version      : <0.2.149.30>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: FAIL
    Firefox 3: OK
         IE 7: Another expression

What steps will reproduce the problem?
1. Try the attached file

What is the expected result?
Chrome should work with arrows keys on "keypress" event.

What happens instead?
Chrome doesn't work on "keypress" event with arrow keys 

 
tt.html
313 bytes   View   Download
Sep 29, 2008
#1 mal.chromium@gmail.com
(No comment was entered for this change.)
Labels: -area-unknown Area-Misc
Sep 25, 2009
#2 virajm...@gmail.com
++

I'm using 3.0.195.21 and see this same issue. Other keys pressed are seen by the 
keypress event but not arrow keys.
Sep 26, 2009
#3 Barzz...@gmail.com
mal@chromium.org, why did you mark this bug as unconfirmed? Is it expected behavior?
It can be easily reproduced, just download html file and open javascript console.
Sep 26, 2009
#4 mal.chromium@gmail.com
I didn't mark it unconfirmed. That is the default status for new bugs. No one on the 
team has ever looked at this.

On the surface, it looks like a WebKit issue, since it fails for Safari too. 

I'll throw it into the WebKit triage pile; someone with more knowledge of those bugs 
might recognize this as a duplicate of another issue.
Status: Untriaged
Owner: ---
Cc: dglaz...@chromium.org o...@chromium.org ka...@chromium.org
Labels: -Area-Misc Area-WebKit
Sep 28, 2009
#5 o...@chromium.org
This is done to match IE. keypress events are only supposed to fire for keys that insert 
characters. Note that keydown/keyup do fire for arrow keys.
Status: WontFix
Jul 23, 2010
#6 iim....@gmail.com
Opera and Firefox catch the "keypress" on an arrow key, they are wrong?
Jul 23, 2010
#7 o...@chromium.org
Keypress events are not specified at this level of detail in any spec, so there's no saying who is right or wrong. WebKit matched IE to maximize web compatibility. It's hard to say who is most correct. In either case, I don't think we could change to match Firefox without breaking a lot of sites.
Sep 9, 2010
#8 dave.mue...@gmail.com
IE is the worst browser in the world.  Why, when building a good browser would you intentionally imitate its strange and (IMHO) illogical failures? I would say that Opera's and firefox's behavior here are more logical, and I don't believe anybody anywhere should accept strange and illogical behavior just because "that's what microsoft does". 
Dec 15, 2010
#9 deos....@googlemail.com
"This is done to match IE" <-- wtf? 
"Why, when building a good browser would you intentionally imitate its strange and (IMHO) illogical failures?" <-- exactly what im thinking right now
this IS a bug (in chromium as well as in IE)

btw, firefox fires keypress from the arrow keys and web-applications are not breaking... but you think they will if you would (correctly) fire the event too?

sorry, this is crazy. please fix this
Mar 5, 2011
#10 dbz11.2...@gmail.com
If this isn't going to be changed, then will someone please explain the logic?
In Firefox:
  keydown: Fires when the key is depressed.
  keyup: Fires when the key is released.
  keypress: Fires when the key is pressed and repeats according to the OS settings for key repeating.
  Fires events for all keys in all events.

In Chrome:
  keydown: Fires when the key is depressed and repeats according to the OS settings for key repeating. Seems rather counter-intuitive by the event name.
  keyup: Fires when the key is released.
  keypress: Fires when the key is pressed and repeats according to the OS setings for key repeating.
  Seems to be biased toward what keys are reported to what event.

Personally I think the approach used in Firefox makes more sense. Why would the keydown event repeat? Why would keypress ignore non-text keys?
Mar 8, 2011
#11 o...@chromium.org
Which approach makes the most sense unfortunately is not the primary driver in this instance. There's a lot of content that depends on the IE behavior. If we changed to match Firefox, it would be at at a significant compatibility hit without much gain given that you can just use keydown.
Mar 8, 2011
#13 o...@chromium.org
@scott, what an example where you can't just use keydown instead of keypress? AFAIK, keydown and keypress both repeat in all modern browsers.
Mar 10, 2011
#14 b-...@b-dur.dk
In currently W3 standard, there is no specification for the key event (http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-keyevents)

There is a DOM Event level 3 specification in the pipeline where the keyevent is specified. So far Chrome and IE has implemented the keyevent correctly according to the draft, relevant to the keypress and keydown behaviour.
(http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/#events-keyboard-event-order)
Oct 11, 2012
#15 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#16 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-WebKit Cr-Content
Apr 5, 2013
#17 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting