Description

Ever since switching from 1.3.x to 1.4.230, I've noticed that mouse up events are sometimes not registered by Mumble, leaving the action that the mouse button corresponds to in an invalid state.

For example, if Push-to-Talk is bound to Mouse 5 and you trigger mousedown and mouseup on Mouse 5, Mumble does not detect mouseup and keeps sending audio to those in the same channel. The only way to fix this is to press Mouse 5 again, triggering mousedown/mouseup.

As I don't know exactly why it happens, the reproduction steps are... iffy. I've seen this behavior on two separate Windows machines running 1.4.230, to two different users (one of which is me). Coincidentally, both users were playing Quake Champions at the time the issues occurred, which might be due to the fact that many inputs are pressed simultaneously during play sessions. Haven't tried other games.

Might have been be caused by 3dc7b00, which changes how both mouse buttons and keyboard keys are handled.

I've personally seen this happen to me twice now, and I've seen it happen several times to someone else. Unfortunately Mumble doesn't provide anything helpful in the developers console, and running my own low-level keyboard/mouse event interception program causes too big a performance hit to effectively use it to see if it sees the mouseup event.

Steps to reproduce

1. Bind Push-to-talk to a mouse button
2. Press lots of other keys/mouse buttons while running resource intensive applications?
3. Press said mouse button

Mumble version

1.4.230

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

No response