[Bug 48322] New: World of Warcraft Classic: Mouse movement can block keydown events from registering
https://bugs.winehq.org/show_bug.cgi?id=48322
Bug ID: 48322 Summary: World of Warcraft Classic: Mouse movement can block keydown events from registering Product: Wine-staging Version: 5.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: m.schaefer8@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
This seems to be a regression:
I've noticed this in the game World of Warcraft Classic. In Wine 4.17.r11 mouse/keyboard behave as expected. With 5.0-rc1 when keeping the right mouse button clicked *and* moving the mouse (changing character orientation and view orientation with the mouse) all other keydown events are ignored. Moving the mouse by itself does not block keydown events; keeping the button pressed but not moving the mouse also does not block keydown events.
Keyup events are processed as normal.
Software I'm using is specifically Wine-Staging with TKG patches.
Having never filed bugs for Wine before, please inform me if you require additional information, logs (and how to acquire said logs), etc.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Please test with plain Wine-Staging first; we don't support outside patches in this tracker.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #2 from m.schaefer8@gmail.com --- (In reply to Zebediah Figura from comment #1)
Please test with plain Wine-Staging first; we don't support outside patches in this tracker.
Sorry, but I'm not going to set up a virtual machine just to get a clean wine install. The entire compile process is an absolute nightmare and I really can't spare a week to figure it all out just for this bug, guess I'll just stop using newer versions of wine. Having tried to just regularly compile staging and running against the BS 32-bit/64-bit procedures, I'm now not sure if I can even run anything here anymore without re-formatting my main drive, because the wine "make install" is the most unreliable script I have ever encountered in my entire life.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- I'd be glad to help you through the process of compiling Wine, it shouldn't take nearly as long as that.
If 'make install' is buggy, please do file a bug report so we can fix it. I don't know why that would be the case, though, we're not doing anything unusual. Note also though that you don't have to install Wine once built; you can just run it from the build directory.
https://bugs.winehq.org/show_bug.cgi?id=48322
Luca Boccassi luca.boccassi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luca.boccassi@gmail.com
--- Comment #4 from Luca Boccassi luca.boccassi@gmail.com --- Hi,
I can confirm I see the same bug, running with unmodified wine, on 3 different machines.
The machines are running Debian 10, with wine-staging packages from winehq's repository (https://dl.winehq.org/wine-builds/debian buster/main).
The regression was first introduced in 4.19. I have to keep the packages pinned to 4.18 to avoid it. I have last tested 5.0~rc1 and the regression was still present.
Let me know if you need any more information or logs.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #5 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Luca Boccassi from comment #4)
Hi,
I can confirm I see the same bug, running with unmodified wine, on 3 different machines.
The machines are running Debian 10, with wine-staging packages from winehq's repository (https://dl.winehq.org/wine-builds/debian buster/main).
The regression was first introduced in 4.19. I have to keep the packages pinned to 4.18 to avoid it. I have last tested 5.0~rc1 and the regression was still present.
Let me know if you need any more information or logs.
Just tried 5.0~rc4, bug is still present.
https://bugs.winehq.org/show_bug.cgi?id=48322
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #6 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #5)
(In reply to Luca Boccassi from comment #4)
Hi,
I can confirm I see the same bug, running with unmodified wine, on 3 different machines.
The machines are running Debian 10, with wine-staging packages from winehq's repository (https://dl.winehq.org/wine-builds/debian buster/main).
The regression was first introduced in 4.19. I have to keep the packages pinned to 4.18 to avoid it. I have last tested 5.0~rc1 and the regression was still present.
Let me know if you need any more information or logs.
Just tried 5.0~rc4, bug is still present.
Have you tried ticking the "Automatically capture the mouse in full-screen windows" option in winecfg?
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #7 from Sveinar Søpler cybermax@dexter.no --- And is a duplicate of https://bugs.winehq.org/show_bug.cgi?id=47764
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #8 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Sveinar Søpler from comment #6)
(In reply to Luca Boccassi from comment #5)
(In reply to Luca Boccassi from comment #4)
Hi,
I can confirm I see the same bug, running with unmodified wine, on 3 different machines.
The machines are running Debian 10, with wine-staging packages from winehq's repository (https://dl.winehq.org/wine-builds/debian buster/main).
The regression was first introduced in 4.19. I have to keep the packages pinned to 4.18 to avoid it. I have last tested 5.0~rc1 and the regression was still present.
Let me know if you need any more information or logs.
Just tried 5.0~rc4, bug is still present.
Have you tried ticking the "Automatically capture the mouse in full-screen windows" option in winecfg?
Yes, that fixes it, just tried in 5.0~rc5, thanks for the tip. But this was not necessary until 4.19, so it still sounds like a regression to me.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #9 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #8)
Yes, that fixes it, just tried in 5.0~rc5, thanks for the tip. But this was not necessary until 4.19, so it still sounds like a regression to me.
Well, yeah, i think it is somewhat of a regression with the "RawInput" patchset in staging.
I cannot verify this with WoW without staging tho, but if i have the time i could perhaps ditch that particular patchset and see what happens.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #10 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Sveinar Søpler from comment #9)
(In reply to Luca Boccassi from comment #8)
Yes, that fixes it, just tried in 5.0~rc5, thanks for the tip. But this was not necessary until 4.19, so it still sounds like a regression to me.
Well, yeah, i think it is somewhat of a regression with the "RawInput" patchset in staging.
I cannot verify this with WoW without staging tho, but if i have the time i could perhaps ditch that particular patchset and see what happens.
Did you manage to find time to try this?
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #11 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #10)
(In reply to Sveinar Søpler from comment #9)
(In reply to Luca Boccassi from comment #8)
Yes, that fixes it, just tried in 5.0~rc5, thanks for the tip. But this was not necessary until 4.19, so it still sounds like a regression to me.
Well, yeah, i think it is somewhat of a regression with the "RawInput" patchset in staging.
I cannot verify this with WoW without staging tho, but if i have the time i could perhaps ditch that particular patchset and see what happens.
Did you manage to find time to try this?
Thanks!
No, sorry. It is multiple patchsets in staging dealing with rawinput and i quite frankly cba to troubleshoot this.
This is with "staging", and it is considered experimental to begin with, and even if i could find what exact patch causes this i kinda doubt anything would be done with it unless i provide a fix for it myself... and that i have no idea of doing.
If someone know exactly what minimal patchsets is needed to run WoW (without me having to sift through a few hundred patches and doing a recompile each time) it would be nice for comparison tho :)
PS. I have no huge issues ticking the "grab mouse" option tho, as i think that works fine most of the time, other than slightly annoying to alt-tab vs. just moving mouse to my 2nd monitor when browsing and stuff like that.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #12 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Sveinar Søpler from comment #11)
(In reply to Luca Boccassi from comment #10)
(In reply to Sveinar Søpler from comment #9)
(In reply to Luca Boccassi from comment #8)
Yes, that fixes it, just tried in 5.0~rc5, thanks for the tip. But this was not necessary until 4.19, so it still sounds like a regression to me.
Well, yeah, i think it is somewhat of a regression with the "RawInput" patchset in staging.
I cannot verify this with WoW without staging tho, but if i have the time i could perhaps ditch that particular patchset and see what happens.
Did you manage to find time to try this?
Thanks!
No, sorry. It is multiple patchsets in staging dealing with rawinput and i quite frankly cba to troubleshoot this.
This is with "staging", and it is considered experimental to begin with, and even if i could find what exact patch causes this i kinda doubt anything would be done with it unless i provide a fix for it myself... and that i have no idea of doing.
If someone know exactly what minimal patchsets is needed to run WoW (without me having to sift through a few hundred patches and doing a recompile each time) it would be nice for comparison tho :)
PS. I have no huge issues ticking the "grab mouse" option tho, as i think that works fine most of the time, other than slightly annoying to alt-tab vs. just moving mouse to my 2nd monitor when browsing and stuff like that.
Is there a process to track regression introduced by patches in staging? Could this bug at least be marked as "confirmed" given there are multiple independent reports?
I have a multi-monitor setup so it is a bit annoying - but not annoying enough to start setting up the build&run environment and bisect, not yet at least :-)
https://bugs.winehq.org/show_bug.cgi?id=48322
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #13 from Zebediah Figura z.figura12@gmail.com --- (In reply to Luca Boccassi from comment #12)
Is there a process to track regression introduced by patches in staging?
Generally, you apply every patch with "path/to/staging-tree/patches/patchinstall.sh --all --backend=git-am --force-autoconf", then bisect between Staging and upstream Wine.
In this case, though, it will likely be better just to check the raw input patches specifically.
Could this bug at least be marked as "confirmed" given there are multiple independent reports?
Sure, though it won't affect anything.
https://bugs.winehq.org/show_bug.cgi?id=48322
devoid42 devoid42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |devoid42@gmail.com
--- Comment #14 from devoid42 devoid42@gmail.com --- Confirming this bug is still present (wine-staging 5.3, Fedora 31), and also in wow-retail as well as classic.
Definitely introduced after the 4.18 rawinput patchset, as me and two other friends have been pinning our releases to 4.17.
Recently we are split, some of us are running current wine-staging but with the "full screen windows capture mouse" setting enabled, but like was pointed out by others this is sub-optimal for multi-screen users.
I've gotten very good at reproducing this for testing, it primarily occurs when you mouse look while trying to input keyboard events. i.e. Right mouse dragging (mouse looking) while trying to push WASD keys to move. The WASD keypresses are only accepted about half the time.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #15 from Luca Boccassi luca.boccassi@gmail.com --- I tried rebuilding without the rawinput patches, but it's still not working. Unfortunately bisecting the entire staging tree is hard, as vanilla wine doesn't work for me.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #16 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #15)
I tried rebuilding without the rawinput patches, but it's still not working. Unfortunately bisecting the entire staging tree is hard, as vanilla wine doesn't work for me.
Kinda what i ended with aswell, as weeding out what patches are needed to get Battle.net to work is not that easy, nor is bisecting whatever caused this kinda hard.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #17 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Sveinar Søpler from comment #16)
(In reply to Luca Boccassi from comment #15)
I tried rebuilding without the rawinput patches, but it's still not working. Unfortunately bisecting the entire staging tree is hard, as vanilla wine doesn't work for me.
Kinda what i ended with aswell, as weeding out what patches are needed to get Battle.net to work is not that easy, nor is bisecting whatever caused this kinda hard.
Rather than bisecting the patchsets, I'm thinking it might be easier to bisect the staging git tree itself, with 4.17 being "good" and 4.18 being "bad"? In _theory_, unless intermittent breakages were added and then removed, it should be doable as both versions work with WoW.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #18 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #17)
Rather than bisecting the patchsets, I'm thinking it might be easier to bisect the staging git tree itself, with 4.17 being "good" and 4.18 being "bad"? In _theory_, unless intermittent breakages were added and then removed, it should be doable as both versions work with WoW.
I am not sure it is "as easy as that", but there was some strangeness that started happening with 4.16 for some games aswell. I am sure this is not ONLY WoW with this problem tho.
This is a bug posted, now marked as solved: https://bugs.winehq.org/show_bug.cgi?id=47834
This is what i gather as something that caused problems aswell: https://github.com/wine-staging/wine-staging/commit/0c7512f5f53deb168d3508bd...
And it was disabled pre 4.18 launch: https://github.com/wine-staging/wine-staging/commit/5b066d6aed7fd90c0be0a2a1...
But i see no tests mentioning WoW in this particular context.
Maybe do some comparison of staging-4.17 vs. 4.17 with these patches enabled/disabled? I think there was changes to the wine tree between 4.17 and 4.18 that prompted the need to update this user32-rawinput patchset tho, but it is way beyond me to figure out the ins and outs of this.
We are playing the "blame-game" here: Is it wine, or is it staging :)
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #19 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Sveinar Søpler from comment #18)
(In reply to Luca Boccassi from comment #17)
Rather than bisecting the patchsets, I'm thinking it might be easier to bisect the staging git tree itself, with 4.17 being "good" and 4.18 being "bad"? In _theory_, unless intermittent breakages were added and then removed, it should be doable as both versions work with WoW.
I am not sure it is "as easy as that", but there was some strangeness that started happening with 4.16 for some games aswell. I am sure this is not ONLY WoW with this problem tho.
This is a bug posted, now marked as solved: https://bugs.winehq.org/show_bug.cgi?id=47834
This is what i gather as something that caused problems aswell: https://github.com/wine-staging/wine-staging/commit/ 0c7512f5f53deb168d3508bdd1f1107ecee774c6#comments
And it was disabled pre 4.18 launch: https://github.com/wine-staging/wine-staging/commit/ 5b066d6aed7fd90c0be0a2a156b0e5c6cbb44bba
But i see no tests mentioning WoW in this particular context.
Maybe do some comparison of staging-4.17 vs. 4.17 with these patches enabled/disabled? I think there was changes to the wine tree between 4.17 and 4.18 that prompted the need to update this user32-rawinput patchset tho, but it is way beyond me to figure out the ins and outs of this.
We are playing the "blame-game" here: Is it wine, or is it staging :)
And the winner is... wine! :-)
I have bisected the wine-staging tree, and the first bad commit was the 4.19 release. That didn't update any patch, but it changed wine's upstream commit from ccec532879ec14b2e79da08288152a69221ec4d1 to 6f2ef158b78f7d0a950c9398c26278d6523c112e. Sure enough, while keeping the wine-staging patches identical, switching the base wine tree between those two commits makes the issue appear/go away.
So I bisected that too, and the culprit is:
https://source.winehq.org/git/wine.git/commit/413aad39135b0b0f8255500b85fcc0... https://github.com/wine-mirror/wine/commit/413aad39135b0b0f8255500b85fcc0533... https://bugs.winehq.org/show_bug.cgi?id=47821
With wine at wine-4.19 plus a revert of that commit, and wine-staging at v4.19, the bug is fixed. Without the revert, the bug is 100% reproducible.
So, what's next? I'm really not familiar with the codebase, so I can't see what the issue is.
https://bugs.winehq.org/show_bug.cgi?id=48322
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #20 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Luca Boccassi from comment #19)
(In reply to Sveinar Søpler from comment #18)
(In reply to Luca Boccassi from comment #17)
Rather than bisecting the patchsets, I'm thinking it might be easier to bisect the staging git tree itself, with 4.17 being "good" and 4.18 being "bad"? In _theory_, unless intermittent breakages were added and then removed, it should be doable as both versions work with WoW.
I am not sure it is "as easy as that", but there was some strangeness that started happening with 4.16 for some games aswell. I am sure this is not ONLY WoW with this problem tho.
This is a bug posted, now marked as solved: https://bugs.winehq.org/show_bug.cgi?id=47834
This is what i gather as something that caused problems aswell: https://github.com/wine-staging/wine-staging/commit/ 0c7512f5f53deb168d3508bdd1f1107ecee774c6#comments
And it was disabled pre 4.18 launch: https://github.com/wine-staging/wine-staging/commit/ 5b066d6aed7fd90c0be0a2a156b0e5c6cbb44bba
But i see no tests mentioning WoW in this particular context.
Maybe do some comparison of staging-4.17 vs. 4.17 with these patches enabled/disabled? I think there was changes to the wine tree between 4.17 and 4.18 that prompted the need to update this user32-rawinput patchset tho, but it is way beyond me to figure out the ins and outs of this.
We are playing the "blame-game" here: Is it wine, or is it staging :)
And the winner is... wine! :-)
I have bisected the wine-staging tree, and the first bad commit was the 4.19 release. That didn't update any patch, but it changed wine's upstream commit from ccec532879ec14b2e79da08288152a69221ec4d1 to 6f2ef158b78f7d0a950c9398c26278d6523c112e. Sure enough, while keeping the wine-staging patches identical, switching the base wine tree between those two commits makes the issue appear/go away.
So I bisected that too, and the culprit is:
https://source.winehq.org/git/wine.git/commit/ 413aad39135b0b0f8255500b85fcc05337a5f138 https://github.com/wine-mirror/wine/commit/ 413aad39135b0b0f8255500b85fcc05337a5f138 https://bugs.winehq.org/show_bug.cgi?id=47821
With wine at wine-4.19 plus a revert of that commit, and wine-staging at v4.19, the bug is fixed. Without the revert, the bug is 100% reproducible.
So, what's next? I'm really not familiar with the codebase, so I can't see what the issue is.
While in works on 4.19, unfortunately reverting that commit on 5.4 breaks wine completely, winecfg doesn't even start, fails with this error:
000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.
So I imagine that functionality is relied upon by something else.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #21 from Sveinar Søpler cybermax@dexter.no --- Well, since this bug still has "New" status, and not confirmed, cos us mere mortals can't be trusted, we shall hope one of the devs have a spare minute or two to read this.
Unless ofc someone provides a patch and submits it tho :)
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #22 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sveinar Søpler from comment #21)
Well, since this bug still has "New" status, and not confirmed, cos us mere mortals can't be trusted, we shall hope one of the devs have a spare minute or two to read this.
There is no CONFIRMED status; NEW is supposed to mean confirmed.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #23 from Luca Boccassi luca.boccassi@gmail.com --- Can someone change the regression sha1 to 413aad39135b0b0f8255500b85fcc05337a5f138, the version to 4.19 and the product to Wine?
https://bugs.winehq.org/show_bug.cgi?id=48322
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|5.0-rc1 |4.19 Component|-unknown |winex11.drv Regression SHA1| |413aad39135b0b0f8255500b85f | |cc05337a5f138 Keywords| |regression Product|Wine-staging |Wine
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #24 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #22)
(In reply to Sveinar Søpler from comment #21)
Well, since this bug still has "New" status, and not confirmed, cos us mere mortals can't be trusted, we shall hope one of the devs have a spare minute or two to read this.
There is no CONFIRMED status; NEW is supposed to mean confirmed.
Ofc you are right. It is "UNCONFIRMED" (when first posted), and then when it is "confirmed" it is set as "NEW" :)
Sorry.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #25 from Luca Boccassi luca.boccassi@gmail.com --- This seems to be fixed in 5.5, although I do not see anything related in the changelog.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #26 from Sveinar Søpler cybermax@dexter.no --- (In reply to Luca Boccassi from comment #25)
This seems to be fixed in 5.5, although I do not see anything related in the changelog.
It is still not fixed for me with <=5.8 unless i tick the "Automatically capture the mouse in full-screen windows" option when using World of Warcraft "Retail 8.3" tho.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #27 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to Sveinar Søpler from comment #26)
(In reply to Luca Boccassi from comment #25)
This seems to be fixed in 5.5, although I do not see anything related in the changelog.
It is still not fixed for me with <=5.8 unless i tick the "Automatically capture the mouse in full-screen windows" option when using World of Warcraft "Retail 8.3" tho.
Seems fixed in wine 7.0 rc5. Please retest. I tried to reproduce this bug on wine 4.19 and wine 5.8 but they crash with the current version of WoW.
https://bugs.winehq.org/show_bug.cgi?id=48322
--- Comment #28 from schaefer m.schaefer8@gmail.com --- (In reply to Zhiyi Zhang from comment #27)
(In reply to Sveinar Søpler from comment #26)
(In reply to Luca Boccassi from comment #25)
This seems to be fixed in 5.5, although I do not see anything related in the changelog.
It is still not fixed for me with <=5.8 unless i tick the "Automatically capture the mouse in full-screen windows" option when using World of Warcraft "Retail 8.3" tho.
Seems fixed in wine 7.0 rc5. Please retest. I tried to reproduce this bug on wine 4.19 and wine 5.8 but they crash with the current version of WoW.
Yeah, seems to be fixed with 7.0. I have a separate issue on 7.0 where sometimes, randomly, keystrokes on the keyboard are now ignored in WoW regardless of mouse-input, but that's most likely unrelated to this issue
https://bugs.winehq.org/show_bug.cgi?id=48322
soredake gi85qht0z@relay.firefox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gi85qht0z@relay.firefox.com
https://bugs.winehq.org/show_bug.cgi?id=48322
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #29 from Zhiyi Zhang zzhang@codeweavers.com --- Marking as fixed.
https://bugs.winehq.org/show_bug.cgi?id=48322
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.0-rc3.
-
WineHQ Bugzilla