EmscriptenKeyboardEvent have different behaviour in Firefox/IE/Chrome #2817

Closed
julianlalu opened this Issue Sep 24, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@julianlalu

When registering keyboard callback with HTML5 API i have different behaviour in Firefox Chrome and IE. I register with emscripten_set_keypress_callback, emscripten_set_keydown_callback and emscripten_set_keyup_callback to the same callback. I print the EmscriptenKeyboardEvent structure and i have different value in different browser.

Here is the complete structure "printf" for each browser for keypress/keydown/keyup:

Chrome (v 37.0.2062.120) spacebar key:

eventType: 2, key: "", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 0, keyCode: 32, which: 32
eventType: 1, key: "", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 32, keyCode: 32, which: 32
eventType: 3, key: "", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 0, keyCode: 32, which: 32

Internet Explorer (v 11.0.9600.17280) spacebar key:

eventType: 2, key: "Spacebar", code: "", location: 0, repeat: 0, locale: "fr-FR", char: " ", charCode: 0, keyCode: 32, which: 32
eventType: 1, key: "Spacebar", code: "", location: 0, repeat: 0, locale: "fr-FR", char: " ", charCode: 32, keyCode: 32, which: 32
eventType: 3, key: "Spacebar", code: "", location: 0, repeat: 0, locale: "fr-FR", char: " ", charCode: 0, keyCode: 32, which: 32

Firefox (v 32.0.2) spacebar key:

eventType: 2, key: " ", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 0, keyCode: 32, which: 32
eventType: 1, key: " ", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 32, keyCode: 0, which: 32
eventType: 3, key: " ", code: "", location: 0, repeat: 0, locale: "", char: "", charCode: 0, keyCode: 32, which: 32

You can note that key attribute is not the same, sometime empty, space or "Spacebar" string. In the documentation key attribute is recommanded and which is deprecated but which is the only attribute which is everywhere the same.

@juj juj added the HTML5 API label Sep 24, 2014

@juj

This comment has been minimized.

Show comment
Hide comment
@juj

juj Sep 24, 2014

Collaborator

The reason why I wrote that which is deprecated and key is recommended came directly from this MDN page: https://developer.mozilla.org/en-US/docs/Web/Events/keypress .

The reason why which is not recommended is that it predates standardization, e.g. mentioned in this page: https://developer.mozilla.org/en-US/docs/Web/API/event.which .

The unfortunate part here is that it looks like the new standard key does not seem to be implemented in new browsers either, which seems to leave a mess to the developer to research what is the best scheme to capture keyevents.

The idea of the Emscripten HTML5 API here is to provide the event structure as-is, untranslated, so I think there is no bug in this API that could be fixed - but perhaps there is a bug in our documentation that does not offer a solution to the developer to do the right thing.

If using which solves all your problems, then by all means, I recommend ignoring the deprecation comment in the docs, since I don't think any browsers will be able to ever kill off that field, and it will continue working for the end of time. What do you think?

Collaborator

juj commented Sep 24, 2014

The reason why I wrote that which is deprecated and key is recommended came directly from this MDN page: https://developer.mozilla.org/en-US/docs/Web/Events/keypress .

The reason why which is not recommended is that it predates standardization, e.g. mentioned in this page: https://developer.mozilla.org/en-US/docs/Web/API/event.which .

The unfortunate part here is that it looks like the new standard key does not seem to be implemented in new browsers either, which seems to leave a mess to the developer to research what is the best scheme to capture keyevents.

The idea of the Emscripten HTML5 API here is to provide the event structure as-is, untranslated, so I think there is no bug in this API that could be fixed - but perhaps there is a bug in our documentation that does not offer a solution to the developer to do the right thing.

If using which solves all your problems, then by all means, I recommend ignoring the deprecation comment in the docs, since I don't think any browsers will be able to ever kill off that field, and it will continue working for the end of time. What do you think?

@julianlalu

This comment has been minimized.

Show comment
Hide comment
@julianlalu

julianlalu Sep 24, 2014

I think for the moment it's a good practice to stay with which. For compatility with browsers until they implement the same stuff in key, and i can stay a good pratice after to keep compatility with older version of browsers.
I will just compare it to the keyCode hexa found here:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.keyCode
It's generally the same value in which.

The Emscripten documentation lost me of how capture key events.

I think for the moment it's a good practice to stay with which. For compatility with browsers until they implement the same stuff in key, and i can stay a good pratice after to keep compatility with older version of browsers.
I will just compare it to the keyCode hexa found here:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.keyCode
It's generally the same value in which.

The Emscripten documentation lost me of how capture key events.

juj added a commit that referenced this issue Sep 24, 2014

Apply comment to HTML5 key event 'which' field to help developers not…
… shy away from it, since it currently has the best cross-browser support. Fixes #2817.

@juj juj self-assigned this Sep 24, 2014

@juj

This comment has been minimized.

Show comment
Hide comment
@juj

juj Sep 24, 2014

Collaborator

I pushed a change to clarify the wording there. Perhaps that can help developers to avoid confusions. Let me know if that wording does not capture the situation properly.

Collaborator

juj commented Sep 24, 2014

I pushed a change to clarify the wording there. Perhaps that can help developers to avoid confusions. Let me know if that wording does not capture the situation properly.

@juj juj closed this Sep 24, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment