Release pressed events when the window is blurred on HTML5 platform #52809
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #49021
On the JS/HTML5 platform, when the user switches to another tab/window, any keys that were held down at the time would stay held down, so when the user switched back to the game window they would have to press the same keys again to release them.
This was due to the fact that we weren't calling the
release_pressed_events()
of theInput
singleton like we do on other platforms. Browsers fire ablur
event on thewindow
object when it loses focus, and it's possible to add a callback handler to the same event in Emscripten.So in this patch we simply add a callback handler to this event and invoke
release_pressed_events()
. In contrast to thefocusout
event which occurs before the focus is lost (and doesn't fire from thewindow
object anyway), theblur
event can bubble, so we just returnfalse
from the callback.Also, we already propagate the
focus
andblur
events and turn them into window notifications via thegodot_js_display_notification_cb()
JavaScript function, so we don't have to do it in the new callback.I don't think we can apply the same patch to the 3.x branch with a cherry-pick because both the location of the patch and the way of accessing the input singleton are a little bit different. Once we're good to go on this I can open another PR for that branch.
See: