[Chrome] Input actions get stuck in the pressed state on web builds

[nyxkn]

Godot version

master (a2f90d5)

System information

Godot v4.2.dev (a2f90d5) - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Thu, 21 Sep 2023 12:54:31 +0000 - Tty - GLES3 (Compatibility) - AMD Radeon R9 380 Series (tonga, LLVM 16.0.6, DRM 3.54, 6.5.4-zen2-1-zen) () - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

Issue description

Input actions get stuck in the pressed state even after releasing the action's key.

This happens only on web exports. I can reproduce the issue reliably on the latest Chrome/Chromium 117. It does not seem to happen on Firefox.

Steps to reproduce

It happens while pressing/releasing keys. One way I've found to reliably reproduce this issue is the following:

Assume we have 3 actions (A, B, C) with their respective keys assigned. Press and hold A, B and C, one after the other. I.e. press and hold A, then add B, then C. Now you're holding down three keys. Now, release the three keys in the same order they were pressed. I.e. release A, then release B, then release C. When you release key C, observe how is_key_pressed() for C returns false, but is_action_pressed() for C still returns true.

I've created a small test project with a basic character controller that moves with the built-in actions ui_{left,right,up,down}. The controller moves by reading the action pressed status with Input.get_vector(). Debug text shows the status of is_key_pressed and is_action_pressed.

To reproduce with this project, you can use any three of these direction keys to trigger the bug. E.g. press and hold left, down, right. Then release left, down, right. Observe how the character keeps moving right, and the action for right still shows as pressed (while the key doesn't).

vokoscreenNG-2023-10-03_16-37-59.mp4

Minimal reproduction project

bug-actions.zip

[vmikhav]

I found similar/the same issue starting from 4.2dev4. After calling Input.action_press with one button several times calling Input.action_release doesn't release the button, it should be called several times (probably as many as action_press was called). Here is the reproducing project
test.zip

[akien-mga]

CC @KoBeWi @Sauermann

[daniel080400]

Got the same issue with 4.2-beta2 too

[MetRiko]

Just tested it with 4.2-beta3 with my jam game - issue is still there unfortunately : /
I tested it on the itch.io using Edge browser.
I tried two movement implementations:
a) just with Input.get_vector(...)
b) using the classic if elif... approach:

func _process(_delta):
	var vec := Vector2()
	if Input.is_action_pressed("ui_left"):
		vec.x = -1.0
	elif Input.is_action_pressed("ui_right"):
		vec.x = 1.0
	if Input.is_action_pressed("ui_up"):
		vec.y = -1.0
	elif Input.is_action_pressed("ui_down"):
		vec.y = 1.0
	_move_direction = vec.normalized()

In both cases bug was still replicable. It's sometimes very hard to get but it's happening frequently enough to make sharing jam games using web builds really risky.

[Sauermann]

I can confirm this issue with Chromium on Linux X11.
Bisecting lead me to #80859.
In my tests, I was unable to replicate this with Firefox (2 minutes of trying)

[KoBeWi]

Well I don't know how to fix it, other than disabling #80859 in web builds. It's obviously a platform-specific issue.

[akien-mga]

@Faless Any idea about what the Web platform does differently input wise which could introduce this discrepancy with other platforms?

[vmikhav]

I have this issue on desktop (windows 10), so web is not the only affected platform.

[KoBeWi]

Can't reproduce on Windows 10, tried both minimal projects.

it should be called several times (probably as many as action_press was called).

This is intended, you need to release the action for each press. Previously when you e.g. pressed action with keyboard and joypad, releasing only one released the action. This was fixed.

[lemilonkh]

We're also experiencing this. It doesn't happen in Firefox on Linux, but does in Edge and Opera GX on Windows 10, as well as in Chromium on Linux.

It's pretty much a showstopper for us, and we're currently building a jam game with 4.2 beta4 since we are using @KoBeWi 's excellent Metroidvania System addon (as well as the new particles among other things).

Let me know if I can help with the fix in any way. Otherwise we will compile our web export template without #80859 for now.

[nyxkn]

@lemilonkh What I ended up doing in my jam game when I ran into this issue is simply to avoid using actions altogether. You can read key presses directly, for example using is_key_pressed(KEY_LEFT) instead of is_action_pressed("left"). It might be a suitable solution if you use simple controls, but YMMV.

[lemilonkh]

@nyxkn Thanks for the workaround. We might either do that or compile the export templates for web without the PR mentioned above.

[Faless]

Testing with the following patch:

diff --git a/platform/web/js/libs/library_godot_input.js b/platform/web/js/libs/library_godot_input.js
index 92113e85c9..c04403472c 100644
--- a/platform/web/js/libs/library_godot_input.js
+++ b/platform/web/js/libs/library_godot_input.js
@@ -454,6 +454,9 @@ const GodotInput = {
 			const modifiers = GodotInput.getModifiers(evt);
 			GodotRuntime.stringToHeap(evt.code, code, 32);
 			GodotRuntime.stringToHeap(evt.key, key, 32);
+			if (!evt.repeat) {
+				console.log(evt.code, pressed);
+			}
 			func(pressed, evt.repeat, modifiers);
 			evt.preventDefault();
 		}

Here is the output from Firefox:

ArrowLeft 1 tmp_js_export.js:10246:12
ArrowUp 1 tmp_js_export.js:10246:12
ArrowRight 1 tmp_js_export.js:10246:12
ArrowLeft 0 tmp_js_export.js:10246:12
ArrowUp 0 tmp_js_export.js:10246:12
ArrowRight 0 tmp_js_export.js:10246:12

Here is the output from Chromium:

tmp_js_export.js:10246 ArrowLeft 1
tmp_js_export.js:10246 ArrowUp 1
tmp_js_export.js:10246 ArrowRight 1
tmp_js_export.js:10246 ArrowLeft 0
tmp_js_export.js:10246 ArrowRight 1
tmp_js_export.js:10246 ArrowUp 0
tmp_js_export.js:10246 ArrowRight 1
tmp_js_export.js:10246 ArrowRight 0

Seems like chrome is firing repeated keydown events with Event.repeat = false for some reason.

Seems to be a browser bug. EDIT: Maybe this regression which regressed again? https://bugs.chromium.org/p/chromium/issues/detail?id=1069690

[Faless]

Indeed, it seems the regression was reintroduced in Chrome at some point.
You can test it using this JSFiddle: https://jsfiddle.net/ys6o5tfg/5/

[Faless]

I've opened a new bug upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=1500634