starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Global shortcuts not registered when dragging Mumble windows #2501

New issue

Open

opened 2026-02-20 22:07:47 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 22:07:47 -05:00

Owner

Originally created by @Snowknight26 on GitHub (May 30, 2022).

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

Open Mumble
Start dragging the main Mumble window by left clicking on the title bar and dragging
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

https://user-images.githubusercontent.com/5608270/170920865-7ab56d64-1a10-4937-acff-010b61561d5b.mp4

Originally created by @Snowknight26 on GitHub (May 30, 2022). ### 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 https://user-images.githubusercontent.com/5608270/170920865-7ab56d64-1a10-4937-acff-010b61561d5b.mp4

deekerman added the

labels

2026-02-20 22:07:47 -05:00

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (May 30, 2022):

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?

@Krzmbrzl commented on GitHub (May 30, 2022): My gut feeling tells me that this might be a limitation of the Windows API that we use for shortcuts :thinking: @davidebeatrici could this be the case?

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Snowknight26 commented on GitHub (Aug 15, 2022):

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:

@Snowknight26 commented on GitHub (Aug 15, 2022): 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

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@davidebeatrici commented on GitHub (Aug 15, 2022):

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.

@davidebeatrici commented on GitHub (Aug 15, 2022): 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.

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Flupster commented on GitHub (Aug 22, 2022):

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

@Flupster commented on GitHub (Aug 22, 2022): 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

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Aug 22, 2022):

@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

@Krzmbrzl commented on GitHub (Aug 22, 2022): @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

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Snowknight26 commented on GitHub (Aug 22, 2022):

@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.

@Snowknight26 commented on GitHub (Aug 22, 2022): > @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.

deekerman commented

2026-02-20 22:07:49 -05:00

Author

Owner

@Flupster commented on GitHub (Aug 24, 2022):

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

https://user-images.githubusercontent.com/8060924/186397566-659df633-9022-462a-828e-d47bbc414337.mp4

@Flupster commented on GitHub (Aug 24, 2022): 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 https://user-images.githubusercontent.com/8060924/186397566-659df633-9022-462a-828e-d47bbc414337.mp4