I assign keypress listener to textarea. When I press Ctrl+Enter, this listener receives event parameter with keyCode value equal to 10. But when I press just Enter, keyCode is equal to 13. It is also 13 for Ctrl+Enter in other major browsers.
This is true for Safari 3.0.4 and WebKit r29711
In my testing, Internet Explorer 7 behaves the same as Safari.
It's a bug that we produce different codes for Ctrl+Enter on Windows and on Mac, but I would qualify it as a Mac-side bug.
In other words, I think that key code should equal 10 for Ctrl+Enter, matching IE.
Sorry, I wan't attentive enough while testing IE7. I tested _keydown_ event in it, and it does produce 10 on ctrl+enter for _keypress_ event.
I'd like to keep this open to track a bug on the Mac side - we don't have this quirk there yet, but we should.
Then please document it! : )
keypress should use the charCode (which is 13) .
This seems correct on Safari Mac but wrong on Safari Windows which returns keyCode 10.
What does the rdar bug say we want to do here?
(In reply to comment #7)
> keypress should use the charCode (which is 13) .
You disagree with above comments - could you please explain why you find them wrong?
(In reply to comment #8)
> (In reply to comment #7)
> > keypress should use the charCode (which is 13) .
> You disagree with above comments - could you please explain why you find them
I think the whole keypress issue is giving me too many sleepless nights.
The reason why I found it wrong was two reasons.
1. It is valuable to be able to do String.fromCharCode(event.keyCode) in a keypress handler.
2. This is what Firefox does.
I think I'm starting to lean towards not touching keypress again and tell people to only use keydown, keyup and textInput.
> 2. This is what Firefox does.
As a general rule, we do what IE does for key handling.
(In reply to comment #10)
> > 2. This is what Firefox does.
> As a general rule, we do what IE does for key handling.
We should update the title to say:
Wrong keyCode for Ctrl+Enter on Mac (should be 10 and not 13)