Not all key codes work in every browser
Closed this issue · 10 comments
The arrow keys (key codes 37, 38, 39, 40) do not work in latest Chrome.
Everything except the arrow keys and a few others (Enter, Backspace) register as key code 0 in latest Firefox.
Code to reproduce:
import Html exposing (text)
import Html.App as App
import Keyboard
main =
App.program
{ init = (-1, Cmd.none)
, update = \code _ -> (code, Cmd.none)
, subscriptions = always (Keyboard.presses identity)
, view = toString >> text
}
The latest browser versions at the time of this writing are Firefox 46.0.1 and Chrome 50.0.
Confirmed on Chromium: Keyboard.ups detects arrows, but Keyboard.presses doesn't.
For context, an old pull request against core, when Keyboard.presses still lived there: https://github.com/elm-lang/core/pull/463.
In particular, the first comment there explains the cause of all this, and what is and what is not possible to achieve in fixing Keyboard.presses.
MDN notes that KeyboardEvent.charCode is deprecated in favor of KeyboardEvent.key, which uses string names for the various flavors of key, including media keys (like "Play" and "Pause") and editing keys (like "Backspace" and "Home").
Here's an example of what that looks like in Firefox 49.0b1:
Left Arrow
Key h ("Vim left arrow")
(The keyCode and keyChar bits are logged using Debug.log in an Elm app that's using 0.17's elm-lang/keyboard 1.0.0.)
@jeremy-w, trying to handle media keys and editing keys and whatnot for keypress is lost effort, since as explained elsewhere and pointed to above, MDN also says that keypress should not fire for those keys at all, and indeed browsers other than Firefox adhere to that specification.
Keypress is lost effort; it's deprecated: The KeyboardEvent also had a char attribute that was only used by the keypress event. Since the keypress event has been deprecated, this attribute was no longer useful and was removed. The media keys are valid keys though, and they should show up AFAICT for not-deprecated KeyboardEvent events.
Keypress is lost effort; it's deprecated
If you go far enough back in the context of this issue here, as linked to above, you will already find the suggestion, by me, to remove Keyboard.presses from Elm altogether. It wasn't done. It's of course possible to open a new issue proposing (again) to remove Keyboard.presses, but the current issue here is about what to do with/for Keyboard.presses while it exists.
And then it's simply a fact that it does not make sense to even try to handle non-character keys, because a) it won't work and b) it shouldn't work. (The very same document you linked to clearly says that keypress should only fire for character keys.)
The media keys are valid keys though, and they should show up AFAICT for not-deprecated KeyboardEvent events.
Yes, but again, that's not relevant for the issue at hand here. The issue at hand here is about Keyboard.presses. (Nobody complains that arrow keys do not work for Keyboard.ups and Keyboard.downs. Because they do.)
Again it might make sense to have an issue open about using key instead of keyCode for Elm's keyboard events. But a) that would have to be a different issue than this one here, for reasons given above, and b) anyway Evan is already aware of that, see the final note in http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Events#keyCode.
I have made a pull request, #5, that at least makes sure the Elm documentation of this subscription agrees with the W3C specification of the underlying event. (It's impossible for the documentation to agree with the behavior in all browsers, since the browsers behave differently, only some of them true to the specification.)
That clears it up. We are not forced to hew to what the browser gives us directly, so we could do things like converting key into a keyCode ourselves in order to better support this within Elm, though, no?
Similarly, we could synthesize press events whenever there's a subscribe and we've observed a down followed by an up event.
Jeremy W. Sherman
https://jeremywsherman.com/ https://jeremywsherman.com/
El 5 ago 2016, a las 00:47, Janis Voigtländer notifications@github.com escribió:
Keypress is lost effort; it's deprecated
If you go far enough back in the context of this issue here, as linked to above, you will already find the suggestion, by me, to remove Keyboard.presses from Elm altogether. It wasn't done. It's of course possible to open a new issue proposing (again) to remove Keyboard.presses, but the current issue here is about what to do with/for Keyboard.presses while it exists.
And then it's simply a fact that it does not make sense to even try to handle non-character keys, because a) it won't work and b) it shouldn't work. (The very same document you linked to clearly says that keypress should only fire for character keys.)
The media keys are valid keys though, and they should show up AFAICT for not-deprecated KeyboardEvent events.
Yes, but again, that's not relevant for the issue at hand here. The issue at hand here is about Keyboard.presses. (Nobody complains that arrow keys do not work for Keyboard.ups and Keyboard.downs. Because they do.)
Again it might make sense to have an issue open about using key instead of keyCode for Elm's keyboard events. But a) that would have to be a different issue than this one here, for reasons given above, and b) anyway Evan is already aware of that, see the final note in http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Events#keyCode http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Events#keyCode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AABxUu13QoaXkNG5FZ_66ChQwrozad6Mks5qcsBvgaJpZM4Ijaj_.
Yes, in theory one could add extra logic on the Elm side to paper over the misbehavior of some browsers. To isolate Elm users from differences between browsers etc. My old pull request against core referenced above tried to do some of that, and in its discussion (the history of it does not begin with that PR, there was an older one that had quite some discussion before Evan asked to start a new one) there were other proposals like actually dropping the non-specification-abiding key presses that Firefox gives for non-character keys. [sarcasm] And look at how successful that PR was. [/sarcasm]
So, in practice, the maximum realistic change I expect can get merged here, with convincing enough justification, is to replace keyCode by which. Given all I know (the lengthy analysis that went into the mentioned old PR), that would be a strict improvement. Keyboard.presses would continue to work in exactly the way it currently does in browsers and situations where it's doing fine, and it would start to work fine in additional browsers and situations. Specifically:
- It would continue to work exactly as it does currently in Chrome.
- It would start to emit events for character keys in Firefox.
@epeterson320, I suggest to close this issue here. It is comprehensively covered by the combination of the following two pull requests: