Global shortcuts not registered when dragging Mumble windows

[Snowknight26]

Description

Whenever a window is being dragged that belongs to the Mumble process, global shortcuts aren't registered. This seems to affect all windows that I tried: main window, settings window, help window, etc. Both keyboard and mouse shortcuts are affected as well.

For example, if you have Push-to-Talk bound to Mouse 5, dragging any Mumble prevents Mouse 5 from being registered as being pressed until the drag event stops.

In the video below, I have a low-level keyboard/mouse hook set, with each key/button press output to the console application on the left. You can see that Mouse 5 (WM_XBUTTON with a 'B' value of '5') corresponds to PTT. When dragging (anything shown after WM_LBUTTONDOWN and before WM_LBUTTONUP [left mouse button down, left mouse button down, respectively]), however, even though Mouse 5 is pressed, Mumble doesn't recognize it.

Steps to reproduce

1. Open Mumble
2. Start dragging the main Mumble window by left clicking on the title bar and dragging
3. While dragging, press a global shortcut

Mumble version

1.4.230

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

2022-05-29_23-58-04.mp4

[Krzmbrzl]

My gut feeling tells me that this might be a limitation of the Windows API that we use for shortcuts 🤔

@davidebeatrici could this be the case?

[Snowknight26]

I've only minimally researched this but it appears that that Windows blocks messages to the main thread during a window move/resize operation. The solution seems to be to create a new thread, separate from the main GUI thread, to process input messages.

I've tested other programs such as foobar2000 which allow global hotkeys to continue to be registered during window move/resize events, so it's definitely possible.

References:

• https://www.qtcentre.org/threads/43036-Moving-window-freezes-event-loop ("I moved it to an own thread")
• https://www.qtcentre.org/threads/51858-Press-Down-click-on-Title-bar-stop-event-loop-(Windows-not-sure-on-linux-or-other-OS) (no solution but describes the issue)
• https://www.qtcentre.org/threads/71514-Qt-project-stops-working-when-changing-location-mainwindow
• https://stackoverflow.com/questions/44259934/qt-mainwindow-resize-drag-event-interfering-with-the-background-thread
• https://stackoverflow.com/questions/18041622/how-do-i-stop-windows-from-blocking-the-program-during-a-window-drag-or-menu-but

[davidebeatrici]

Yes, that's why in a lot of programs the progress bar freezes during a move/resize operation.

I guess we'll have to create a hidden invisible window.

[Flupster]

Another note to add

If you drag a user or channel while your push to talk is activated and then let go of your push to talk while the user / channel is now off the mumble window the push to talk will not register the deactivation of the push to talk and will be activated indefinitely or until you activate your push to talk for a second time

[Krzmbrzl]

@Flupster does this also happen with Mumble 1.4.274 (released yesterday)? 'cause there has been a fix thst I think might also apply to your scenario

[Snowknight26]

@Flupster does this also happen with Mumble 1.4.274 (released yesterday)? 'cause there has been a fix thst I think might also apply to your scenario

Yep, definitely happens with 1.4.274 as well.

[Flupster]

As an example I've created a quick video to demonstrate the unwanted behaviour

Any time the PTT is activated in the video for an extended period of time the PTT is actually not being held anymore

mumble2.mp4