GLFW key listener blocking backspace and tab

https://github.com/kripken/emscripten/blob/incoming/src/library_glfw.js#L400

Why is it necessary to call event.preventDefault() when the key is backspace or tab here? This blocks backspace and tab on the entire page, making text inputs on the page completely unusable.

I'm not sure I understand the purpose of this anyways. Is it to prevent the user from exiting the page when they hit backspace? If so, maybe this should only be checked if the pointer is locked or fullscreen is enabled.

[juj]

Commented about this in detail in the PR. Indeed the current behavior blocks on interacting with input on other DOM elements, and generally people have solved this by using the HTML5 Input API, where this is designed to be controllable per event. GLUT/GLFW/SDL each have defaulted to more or less assuming that the only interesting element on the page is the canvas, which has dedicated focus, since that helps most projects get going.

Smarter heuristics are definitely welcome, but we should be careful not to get into a "whose use case is the most important one to be the default?" debate. Perhaps some Emscripten-specific configuration options for GLUT/GLFW/SDL APIs might be in order?

@juj Do you mind linking to some documentation about the HTML5 Input API? I'm afraid I don't know which API you're talking about, nor can I find it on Google. Is it the same as addEventListener/removeEventListener?

Are you sure that smarter heuristics are really a worthwhile solution here (read: even more uncontrollable magic code)? What do you think about a configuration option that ties the existing functionality to just the canvas so that everyone can have their own desired level of control?

var myModule = Module({
    attachGLFWEventsToCanvas: true
});

library_glfw.js, glfwInit():

...
var eventTarget = window;
if(Module['attachGLFWEventsToCanvas']) eventTarget = Module['canvas'];
eventTarget.addEventListener("keydown", GLFW.onKeydown, true);
eventTarget.addEventListener("keypress", GLFW.onKeyPress, true);
eventTarget.addEventListener("keyup", GLFW.onKeyup, true);
eventTarget.addEventListener("blur", GLFW.onBlur, true);
...

[juj]

@juj Do you mind linking to some documentation about the HTML5 Input API? I'm afraid I don't know which API you're talking about, nor can I find it on Google. Is it the same as addEventListener/removeEventListener?

The API I'm referring to is the file #include <emscripten/html5.h>. See http://kripken.github.io/emscripten-site/docs/api_reference/html5.h.html and https://github.com/kripken/emscripten/blob/incoming/system/include/emscripten/html5.h .

Are you sure that smarter heuristics are really a worthwhile solution here (read: even more uncontrollable magic code)? What do you think about a configuration option that ties the existing functionality to just the canvas so that everyone can have their own desired level of control?

Hmm, does that work? If one listens on blur on the canvas rather than window, does that come through? I wonder if having an option to choose to listen on all events on either window vs canvas is enough?

same + 1. Glfw event listener ( event.preventDefault() for backspace and tab ) makes inputs unusable.