[Web] Prevent default key inputs only if the key is not modified

[adamscott]

This PR changes how keyboard input is neutralized from having side effects in the browser.

Beforehand, every key input default behavior would be prevented, no matter which one they were. Unfortunately, it leaves some issues, such as not being able to spawn the developer tools, or worst even, not being able to refresh the browser nor being able to quit it via keyboard shortcuts.

This PR inspires itself from the behavior of Phaser.js.

If a key is being modified by Alt, Shift, Control, or Meta, we don't prevent default. This would reenable most browser shortcuts.

I also added function keys to the list of keys that cannot be "prevented".

Follow-up to #86178 Fixes #86175

[Faless]

If a key is being modified by Alt, Shift, Control, or Meta, we don't prevent default. This would reenable most browser shortcuts.

I don't particularly like this, games that bind both R and the CTRL button would be at risk of the user accidentally refreshing the page.

Likewise, it would make it impossible to bind any FN key since most of them have side effect (potentially interfering with your game).

I honestly think there's nothing worse than accidentally pressing a button, and losing all your game progress because of a dummy browser behavior.

Why would a player ever open the DevTool??? (#86175). A game is not a regular web page, you don't want to reload it, almost never. DevTool are for development (and you can open them via the browser menu anyway, or by clicking outside of the page, and then pressing F12).

I suggest we at least allow the devs to use the old behavior (which IMO should also still be the default, but I can live with it being an export option).

EDIT: I think the only meaningful shortcut for end users is the CTRL/META+V paste event, and only because browsers can't be bothered to properly implement a decent Clipboard API

[adamscott]

Will close in order to find a better solution.

[ci-bo]

"Why would a player ever open the DevTool???" -- That was not suggested. DevTools are for the developer users of Godot. Does it follow that those users must be disallowed from using conventional browser hotkeys under any circumstances?

I'm sympathetic to Faless's painful memories of losing progress after pressing F5. This concern well-justifies the default behavior for F5. Conversely, I've never heard of a user losing progress because they pressed F12 and accidentally toggled the console, so we shouldn't conflate them. It remains unexplained how developers are best served by Godot swallowing and ignoring certain hotkeys with no recourse, and unexplained why Godot must suppress and cancel the user's intent as much as the OS and browser allows. If it were possible, would Godot overrule Alt-Tab and Ctrl-Alt-Delete so the user doesn't accidentally skip away from a good part? Users "almost never" need to press those shortcuts, after all. We accept they must be allowed to, covering the unintended cases where changing the window or ending the process is the user's requirement. If we had the ability to suppress those shortcuts, the option to retain them would be at least obscurely accessible. Refreshing and opening the console are less frequent operations than e.g. the arrow keys, certainly -- less frequent, but not negligible.

A developer might need to refresh or toggle the console dozens or hundreds of times. Suggesting that they habituate themselves to extra clicks to defocus the game or go through the browser UI (the only option, if your game covers the window and can't be clicked out from!) is a suggestion for the multiplication of labor. A long way is a poor substitute for a shortcut.

An easy compromise might be to leave the current behavior as default, but provide an advanced option in the exporting parameters to prevent overriding the input captures for common browser shortcuts for web developers interested in retaining the standard quick keyboard access to the console or refreshes. Such an option would not be out of place with the other advanced options for debug builds.

Worst case scenario, you opt in to allowing it, deploy your debug build by accident and a QA user refreshes or toggles their console without knowing what they did -- not a complicated fix (uncheck the box you checked to allow hotkeys for browser refreshes and console toggles).