[Bug 45385] New: Wrong state of virtual keys after cycling windows. Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every key can be affected.

https://bugs.winehq.org/show_bug.cgi?id=45385

Bug ID: 45385
           Summary: Wrong state of virtual keys after cycling windows.
                    Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every
                    key can be affected.
           Product: Wine
           Version: 3.9
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wineserver
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

I noticed that the state of the keys sometimes sticks in pressed state.

This happens when cycling windows with some shortcut key combination.

For example if cycling with Alt+Tab, on pressing Alt, the program gets
WM_KEYDOWN and the state of the VK_MENU becomes pressed. But after cycling
windows, the program does not get WM_KEYUP because the window is not focused
and VK_MENU (and the respective VK_LMENU or VK_RMENU) remain in pressed state.

When cycling back to the program window, the window get focused only after
releasing Alt key, so it does not get this event as well.

If cycling windows with another shortcut key combination (for example
Alt+Shift+Tab - for backward cycling) both VK_MENU and VK_SHIFT keys stick.

In the same time, GetAsyncKeyState returns the proper state of the keys.

Note1: The problem is obviously in the wineserver code, because it handles the
key state tables for the different threads.

Note2: The effect happens only sometimes. It seems the code for proper
processing is already there, but some racing conditions have place.

Note3: There is some probability that the effect is in result of my application
code, but it never happens on real Windows, so I considered it a bug.

Note4: I tried to workaround this problem by reading the whole table by
GetAsyncKeyState and setting it then with SetKeyboardState on WM_ACTIVATE
message of the main window. This workaround actually works, but is too ugly
IMO.
The same trick on WM_ACTIVATEAPP does not work.

[Bug 45385] Wrong state of virtual keys after cycling windows. Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every key can be affected.

https://bugs.winehq.org/show_bug.cgi?id=45385

Kai Krakow  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Kai Krakow  ---
I wonder if this is a similar problem as very short presses of gamepad buttons
are sometimes not registered in games. This is only a problem with games
running in Wine, native Linux games do not show this behavior.

[Bug 45385] Wrong state of virtual keys after cycling windows. Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every key can be affected.

https://bugs.winehq.org/show_bug.cgi?id=45385

--- Comment #2 from John Found  ---
I have found a workaround. At first, I am testing under XFCE. There are two
options in the "Windows manager tweaks" settings applet:

[ ] Activate focus stealing protection
 [ ] Honor ICCCM focus hint

So, I have discovered that the bug manifests itself only when both settings are
switched ON. Unchecking any of them makes the bug to disappear.

Still it is not very clear where is the bug actually - in the code of the XFCE
WM or in WINE. Any ideas about future testing/diagnostics are welcome.

[Bug 45385] Wrong state of virtual keys after cycling windows. Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every key can be affected.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=45385

Julian Rüger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]