[Bug 44032] New: Diablo 3 2.6.1: Mouse-downs register as mouse clicks
https://bugs.winehq.org/show_bug.cgi?id=44032 Bug ID: 44032 Summary: Diablo 3 2.6.1: Mouse-downs register as mouse clicks Product: Wine Version: 2.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sts33nvyb(a)gmail.com Distribution: --- Created attachment 59696 --> https://bugs.winehq.org/attachment.cgi?id=59696 Terminal output (not that I expect this to be useful) In Diablo 3, mouse-downs (pressing and holding the mouse button) often register as mouse clicks (pressing and immediately releasing the mouse button). This happens for approximately 50% of the mouse-downs when playing the game, which dramatically changes how the game plays, since holding down the mouse button is used for both moving and attacking continuously in the game. I'm running wine-staging 2.20 on OpenSuse 42.3 x86_64. This is for the current version of Diablo 3, version 2.6.1.47919 32-bit. Note that Diablo 3 recently dropped support for Windows XP; since this change, Diablo 3 no longer works in non-staging wine at all. Also, the 64-bit version of Diablo 3 has severe performance problems in wine-staging 2.20, so this is using the 32-bit version of Diablo 3. I speculate that some bug in wine is causing bogus mouse-up events to sometimes be generated immediately after mouse-down events. Note that this is a completely different bug from bug 31262. Note that user "pakos" has mistakenly commented about this bug in that bug report, dated 2017-11-13. He reports that this problem is present in versions of wine-staging at least back to 2.5. There has been some discussion of this bug on the application page. Some users have reported that changing wine's virtual desktop setting, forcing 32-bit using setarch, or changing Diablo 3's settings to windowed-fullscreen instead of fullscreen alleviated the problem. None of these helped for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #1 from Steve Soule <sts33nvyb(a)gmail.com> --- Some more testing results: The problem also happens in 64-bit Diablo 3. The 64-bit version has a frame rate of only about 1 FPS, so it's unplayable, but this mouse-down problem is easy to test, and it does happen. I've also tried using a 32-bit wine prefix. This does not help; the problem still happens. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #2 from Steve Soule <sts33nvyb(a)gmail.com> --- I've gone through the 440 patches of wine-staging 2.20 and found which one seems to be responsible for this problem: the patch "server-send_hardware_message". With just the patches "kernel32-SetFileCompletionNotificationModes" and "ntdll-FileNameInformation" (which are necessary for Blizzard app to work) applied to vanilla wine 2.20, the problem is gone. With the single patch "server-send_hardware_message" applied as well, the problem occurs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Wine |Wine-staging CC| |erich.e.hoover(a)wine-staging | |.com, michael(a)fds-team.de, | |sebastian(a)fds-team.de Component|-unknown |-unknown -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #3 from Steve Soule <sts33nvyb(a)gmail.com> --- I just tested again with wine 2.21 and wine-staging 2.21. As before, the patch server-send_hardware_message triggers this problem for me, and leaving it out (and just using kernel32-SetFileCompletionNotificationModes) makes the problem disappear, for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 xardas01 <xardas01(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xardas01(a)gmail.com --- Comment #4 from xardas01 <xardas01(a)gmail.com> --- I am also having this problem. Every second mouse click is like mouse down/up event. Is there any fix? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #5 from Steve Soule <sts33nvyb(a)gmail.com> --- xardas01: Yes, there is a fix, though it's not a convenient one. As I wrote above, you need to compile non-staging wine 2.21 with one patch from wine-staging 2.21: the patch "kernel32-SetFileCompletionNotificationModes". This one patch is necessary for Blizzard App to work. You can't use full wine-staging 2.21 because it includes a patch, the patch "server-send_hardware_message", that triggers this mouse-downs-register-as-mouse-clicks problem. Unfortunately, compiling wine for yourself is not trivial. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Robert Walker <bob.mt.wya(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya(a)gmail.com --- Comment #6 from Robert Walker <bob.mt.wya(a)gmail.com> --- Re: "hit and run" question on #gentoo-wine ... For anyone that's hitting this issue on Gentoo... cd "<Portage Directory>/app-emulation/wine-staging/" sed -i -e '\|set -- DESTDIR="${S}" --backend=eapply --no-autoconf|{s|--all|kernel32-SetFileCompletionNotificationModes|}' wine-staging-2.19.ebuild ebuild wine-staging-2.19.ebuild manifest Will disable all the Wine Staging patchsets, for the 2.19 ebuild on Wine Staging, apart from: kernel32-SetFileCompletionNotificationModes -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Adam Bolte <abolte(a)systemsaviour.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte(a)systemsaviour.com --- Comment #7 from Adam Bolte <abolte(a)systemsaviour.com> --- I've spent hours on this, and haven't gotten anywhere. I'm in Act III at Bastion's Keep Stronghold, and nothing I do allows me to avoid this bug. I tried all wine-staging patches against 2.21 except server-send_hardware_message by applying the patches like so. ./patchinstall.sh DESTDIR=../../git --all -W server-send_hardware_message I also tried building wine-3.0-rc1 and applied only the kernel32-SetFileCompletionNotificationModes patch. No dice. Then I tried doing the same to 2.21. Then I went back to looking at my older wine-staging builds for comparison (eg 2.16-staging). Made no difference. The bug is easy to reproduce. Launch Battle.net as usual. 64-bit is too slow to be playable, but either 32-bit or 64-bit mode trigger the bug. Once in, I hold down shift so my character is stationary, and then at the same time hold down the left mouse button. The first time this happens, the hero will continue attacking until the mouse button is released. This is the expected behaviour. Still holding down shift, click and hold the mouse button a second time. Only a single attack will be performed, and then nothing. The result wasn't expected to change. Then trying again will cause it to work, trying once more and it won't, etc. Every second time the attack button is held down, the game will not register that the button is held down. I expect this would make the game too frustrating to play at higher difficulty settings. I would love to know why removing the server-send_hardware_message patch solves the problem for you, but not for me. I'm running Debian GNU/Linux 9.3 (Stretch) and an Xfce desktop on an i7-6700k, 32Gb RAM, and ATI RadeonHD 5870 graphics card at 2560x1440 with Linux kernel 4.15.0-rc1 (radeon kernel module), Mesa 17.4.0-devel (git-4c7af87fb9). My mouse is a Logitech G502. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #8 from Steve Soule <sts33nvyb(a)gmail.com> --- Adam, have you tried tweaking the various settings related to windowed mode and desktop emulation? Several people on the Diablo 3 appdb page reported that this helped for them. My computer: OpenSuse 42.3 x86_64, KDE, i5-4460, 8 GB RAM, Nvidia GTX 460, 1920x1200, kernel 4.4.92-31, nvidia driver 384.98, mouse Logitech G402. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Andreas <andi(a)errornet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andi(a)errornet.de --- Comment #9 from Andreas <andi(a)errornet.de> --- First of all thanks for your research "Steve Soule". I was struggeling with the same problem and solved it because of your research! Thanks for that! ;) the only thing that i am missing at the moment is that i normaly play d3 for better performance with gallium nine enabled. like i submited on the link below, the mouse bug appears again if i activate the gallium-nine feature. https://github.com/iXit/Mesa-3D/issues/298 looks like the gallium nine patchset includes something similar to the "server-send_hardware_message" patch from staging patchset. like i explained in the last part of my bug report on ixit, i got the same bug a few yours ago while i was testing to install diablo 3 in a new wineprefix with "windows 7" as windows version. changing on the same wineprefix back to windows xp solved the problem and the mouse bug disappeard. i have been on wine-any at this time which is (wine-vanilla + staging + d3d9). because of this i think that something in "server-send_hardware_message" has to be changed to work together with "windows 7" as windows version. My Computer: Gentoo x86_64, xfce, AMD Phenom(tm) II X6 1100T, 16GB RAM, amd rx470, 3 monitors in a strange arrangement ;) , kernel 4.14.5, mesa 17.2.6, mouse Roccat Kone+ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #10 from Adam Bolte <abolte(a)systemsaviour.com> --- Thanks Steve - that's exactly what it was. I tested various combinations of the options listed under the winecfg Graphics tab, and what I discovered was that in addition to the patched version of Wine, "Automatically capture the mouse in full-screen windows" needs to be disabled, and "Emulate a virtual desktop" needs to be enabled. Setting "Desktop size" to the same resolution as my monitor worked best - 2560x1440 in my case. I tried 1920x1080 initially, but then the keyboard wouldn't work and the Wine Windows taskbar was displayed over the top of the game until I clicked around on it. The middle two winecfg options "Allow the window manager to decorate/control the windows" made no difference regardless of being enabled or disabled. I also tested wine + wine-staging (minus the bad patch) + d3d9 and the issue returned. In the winecfg Staging tab, disabling the "Enable Gallium Nine for better D3D9 graphic performance" and instead selecting the option "Enable CSMT for better graphic performance", I was able to get the game working correctly again. Certainly not as good as using the d3d9 patch set, but better than nothing. I should note that before I retested the above, I had replaced my RadeonHD 5870 graphics card with a Fury X. I doubt it made a difference as far as this bug report goes, but worth mentioning. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #11 from Steve Soule <sts33nvyb(a)gmail.com> --- I've just tested with wine-staging 3.3, and the problem is unchanged. With all patches applied, the mouse-downs-register-as-mouse-clicks problem is present; with the single patch "server-send_hardware_message" removed, the problem is not present and Diablo 3 works normally. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Maciej Stanczew <maciej.stanczew+b(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b(a)gmail.com --- Comment #12 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Is anyone who experiences this bug using Battle.net voice chat during the game? I seem to have this issue when I have voice chat in progress. Every second mouse-down will register as a single click. But the moment I disconnect from it (using the green "Leave voice chat" button), the issue stops appearing -- all mouse-downs register properly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #13 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- I have done some debugging of queue_mouse_message function and have found the following: - Pressing the mouse button calls this function twice: first call has input->mouse.flags = 0x8003 (MOVE|LEFTDOWN), second = 0x8001 (MOVE). - Releasing the button calls it with input->mouse.flags = 0x8005 (MOVE|LEFTUP), and then, after about ~1 ms, an injected event is generated (hook_flags = 1, input->mouse.flags = 1, input->mouse.time = 0). - Without Voice chat enabled, all above events return 0 from call to 'send_hook_ll_message' that is assigned to 'wait' variable. - With Voice chat enabled the above call to 'send_hook_ll_message' *always* returns 1. With the 'server-send_hardware_message' patchset reverted, this is the only change in behavior. - With the 'server-send_hardware_message' in place (not reverted) however, on every second mouse-down the injected event appears after the mouse is *pressed* instead of released (releasing the mouse generates just the MOVE|LEFTUP event, without the following injected event). This is the problematic point -- there was a mouse-down event, but the game behaves as if the button was immediately released. Can someone knowledgeable in this area look into the issue? I have 100% reproduction of the bug, I can gather whatever logs would be needed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45875 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #14 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Maciej Stanczew from comment #13)
Can someone knowledgeable in this area look into the issue? I have 100% reproduction of the bug, I can gather whatever logs would be needed.
I have a hard enough time wrapping my head around whether the patch is even fundamentally correct, but in the interest of furthering diagnosis, can you please attach a log with +server,+event,+hook? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #15 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 62403 --> https://bugs.winehq.org/attachment.cgi?id=62403 +server,+event,+hook without voice chat -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #16 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 62404 --> https://bugs.winehq.org/attachment.cgi?id=62404 +server,+event,+hook with voice chat -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #17 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Attached, but there was so much noise that the log was over the size limit and I had to split it. In both voice chat states I did a couple of press-release cycles, with about 2-3 seconds between each action. In the first half of both logs I did a press, then move the mouse (to confirm my character is following the cursor), and then release. In the second half I held shift (which is "attack in place"), then mouse press, confirm that my character is attacking continuously (and not just once), then release. With voice chat disabled all actions were registered correctly. With voice chat enabled there were problematic mouse-downs at timestamps 11484, 11496, 11519, 11526 (moving the mouse -> character only goes to the place clicked initially), and 11540, 11550, 11556 (holding shift -> character attacks only once). One thing that stands out is "HOOK_CallHooks" mask, which gets changed from 80010000 to 8001c000 when voice chat is enabled (and back to 80010000 when it's disabled -- it's not shown in attached logs, but I tested it afterwards). I don't know if it's related, or just a side effect. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #18 from Zebediah Figura <z.figura12(a)gmail.com> --- The addition of flags 0xc000 means that WH_KEYBOARD_LL and WH_MOUSE_LL hooks were set. Bizarrely, your log seems to only contain output from one thread in it, and I don't see any attempts to call hooks from that thread. I also don't see any +server output. Did you do any filtering of the log (besides just clipping it)? If +server doesn't work, can you try +msg instead? My simplest guess is that somehow the game doesn't expect to receive some message until the hook is done executing, but I don't know what message that would be. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #19 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- I noticed after the fact that +server logs are not present because I launched Battle.net App as the first process and Diablo III (with logs) as second. However with +server there are so many logs that 5 seconds of them take over 7 MB, which is already over the limit (and the whole process took me about 1.5 minutes). I'll see with +msg, and if +server is still required, I'll try to gather them for a single press-release iteration. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #20 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Maciej Stanczew from comment #19)
I noticed after the fact that +server logs are not present because I launched Battle.net App as the first process and Diablo III (with logs) as second. However with +server there are so many logs that 5 seconds of them take over 7 MB, which is already over the limit (and the whole process took me about 1.5 minutes).
I'll see with +msg, and if +server is still required, I'll try to gather them for a single press-release iteration.
Yep, +server logs attach to the first tty that wine was launched from; should have mentioned that. But yeah, they can be heavy. Hopefully +msg should be enough to provide what I'm looking for. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Maciej Stanczew <maciej.stanczew+b(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62403|0 |1 is obsolete| | Attachment #62404|0 |1 is obsolete| | --- Comment #21 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 62406 --> https://bugs.winehq.org/attachment.cgi?id=62406 +msg,+event,+hook I capped the game's FPS at 8 and now there is less noise in the logs -> they can fit all in the size limit. In this log first scenario is with voice chat, and issue appears at timestamps 17320, 17342, 17362, 17375 and 17386. Voice chat was disabled at 17394 and the issue did not appear from this point until the end. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #22 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 62408 --> https://bugs.winehq.org/attachment.cgi?id=62408 +server,+event,+hook And log with +server, for a single press-release (I still had to zip it). This is the problematic one, that the game registered as a click instead of mouse-down. If needed I can attach working iterations for comparison. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #23 from Zebediah Figura <z.figura12(a)gmail.com> --- One discrepancy I can see is that MsgWaitForMultipleObjects() will return early if a hardware message is received, even though no window message has been delivered to the thread's queue yet. I'd be surprised if this is throwing off the application, but finding other discrepancies has as yet been difficult. Trying to write a patch to fix this discrepancy is less than trivial; I'm working on it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 zzzzzyzz(a)hacari.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz(a)hacari.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45938, | |https://bugs.winehq.org/sho | |w_bug.cgi?id=46021 --- Comment #24 from Zebediah Figura <z.figura12(a)gmail.com> --- Making a note of other bugs related to this patch set. I'm not going to mark them as duplicates, since I haven't been able to determine the exact problem, and it may be different. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=46052 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #25 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- The problematic patchset (server-send_hardware_message) was removed from wine-staging, please retest with wine-staging-3.21. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #26 from Steve Soule <sts33nvyb(a)gmail.com> --- Unfortunately, I can no longer reproduce this bug, even with wine-staging 3.3. When I last tested, in March 2018, I was able to reproduce this bug with wine-staging 3.3. I also tried wine-staging 3.21 just now, and, as expected, the bug does not happen for me with it either. Things I know have changed for me since March: - Diablo 3 version: is now 2.6.1.51663 (was 2.6.1.49508 or newer) - Linux kernel version: is now 4.4.162-78 (was 4.4.92-31 or newer) - nvidia driver version: is now 390.87 (was 384.98 or newer) Things I know have not changed for me since March: - wine version (still wine-staging 3.3) - my hardware - my linux distribution version (still opensuse 42.3 x86_64) - my Diablo 3 wine prefix directory (except for the updates to Diablo 3 itself). Unless someone can suggest some configuration change that I might easily make that will allow me to reproduce the bug, I'm afraid my usefulness as a tester for this bug is at an end. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 --- Comment #27 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- I can still do it with voice chat enabled (as described in comment #12). And sure enough, I have reproduction in Wine Staging 3.19, and no repro in 3.20 and 3.21. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e4a3b5fc9d5ed7c102b1618270e | |26a1fcac2d53e Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #28 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- (In reply to Maciej Stanczew from comment #27)
I can still do it with voice chat enabled (as described in comment #12). And sure enough, I have reproduction in Wine Staging 3.19, and no repro in 3.20 and 3.21.
Alright, marking FIXED then. Thanks for reporting back! If someone can still reproduce this, feel free to reopen. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44032 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #29 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing Fixed Staging bugs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org