November 2022 - Wine-Bugs - list.winehq.org

[Bug 53984] New: Broken minimize-restore logic in conhost.exe for all console apps
by WineHQ Bugzilla Nov. 28, 2022

Nov. 28, 2022

https://bugs.winehq.org/show_bug.cgi?id=53984 Bug ID: 53984 Summary: Broken minimize-restore logic in conhost.exe for all console apps Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: x1917x(a)gmail.com Distribution: --- Created attachment 73566 --> https://bugs.winehq.org/attachment.cgi?id=73566 Issue log for minimize-restore There is an old bug in Wine's conhost.exe, introduced years ago. Whenever a console window is minimized and then restored, conhost.exe creates both vertical and horizontal scrollbars for that window, no matter that there were no changes to that window. Bad consequence is that both of them overlap parts of content of the console window, so now one have to actually scroll the window to see the lines/columns covered by scrollbars. >From what I see, the bug affects all console apps, the attached log file was taken for Wine's cmd.exe (wineconsole cmd.exe). The root cause of the bug is that conhost.exe makes no distinction between WM_SIZE caused by regular resize and WM_SIZE caused by minimizing. Whenever the console window gets minimized, ShowWindow(SW_MINIMIZE) is being called for it. Internally, Wine's show_window() calls window_min_maximize() to retrieve the minimized window Rect. For a minimized window it fills that Rect with the size of "iconic" window, which is determined by get_system_metrics(SM_CXMINIMIZED) and get_system_metrics(SM_CYMINIMIZED). Not sure if it depends on the host, but on my system it is 160 x 31. So eventually WM_SIZE(<...>, 160, 31) is being sent to conhost.exe's window, among few other WM_-messages. As conhost.exe makes no distinction between the different states the console window can be, it assumes that the minimized window size (160x31) is the new real window size. Then it tries to apply the same sequence of actions like for any received WM_SIZE. One of them is checking if the newly resized console window is smaller than its content. If it was the case, it creates respective horizontal/vertical scrollbars in window.c/update_window(). So basically, conhost.exe treats every window minimizing as a resize. Luckily, the fix is trivial - Wine's conhost.exe shouldn't try to resize its window when it is minimized. There is zero point to resize a minimized window, especially if it wasn't resized at all. case WM_SIZE: if (console->window && console->window->update_state != UPDATE_BUSY) resize_window( console, --> case WM_SIZE: if (console->window && console->window->update_state != UPDATE_BUSY && !IsIconic(console->win)) resize_window( console, (the patch is attached) Please review and apply the proposed fix if it's ok (I am not a Wine contributor - don't know how to commit to Wine, not a member of the mail list etc). -- 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.

1 2

[Bug 53272] New: user32:msg - test_showwindow() sometimes fails on Windows
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=53272 Bug ID: 53272 Summary: user32:msg - test_showwindow() sometimes fails on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:msg - test_showwindow() sometimes fails on Windows: msg.c:5167: Test failed: ShowWindow(hwnd, SW_RESTORE): active minimized overlapped: 3: the msg 0x0086 was expected, but got msg 0x0046 instead msg.c:5177: Test failed: ShowWindow(hwnd, SW_SHOWNOACTIVATE): active minimized overlapped: 3: the msg 0x0086 was expected, but got msg 0x0046 instead https://test.winehq.org/data/patterns.html#user32:msg Note: * WM_WINDOWPOSCHANGING 0x0046 * WM_NCACTIVATE 0x0086 These failures have happened on w10pro64-hi-u8, w10pro64-pt-BR, w10pro64-ru and w10pro64-zh_CN. However the failures are quite rare so this may not imply that they are related to the locales. -- 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.

1 2

[Bug 53444] New: user32:msg - test_mouse_ll_hook() sometimes gets an unexpecteg mouse position on Windows
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=53444 Bug ID: 53444 Summary: user32:msg - test_mouse_ll_hook() sometimes gets an unexpecteg mouse position on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:msg - test_mouse_ll_hook() sometimes gets an unexpected mouse position on Windows: input.c:1368: Test failed: Wrong new pos: (100,100) https://test.winehq.org/data/patterns.html#user32:input This happens on all Windows versions, from Windows 7 to Windows 10 21H2, except, it seems, Windows 8. The invalid mouse position changes from run to run but it seems there are only 14 possible values (out of 550 failure cases), probably because they all come from missed updates. Wrong new pos: (0,0) Wrong new pos: (100,100) Wrong new pos: (100,99) Wrong new pos: (101,103) Wrong new pos: (102,103) Wrong new pos: (103,102) Wrong new pos: (103,103) Wrong new pos: (140,140) Wrong new pos: (149,149) Wrong new pos: (150,150) Wrong new pos: (160,160) Wrong new pos: (200,200) Wrong new pos: (75,75) Wrong new pos: (99,100) -- 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.

1 5

[Bug 53518] New: riched20:editor - test_EN_LINK() sometimes fails on Windows 10
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=53518 Bug ID: 53518 Summary: riched20:editor - test_EN_LINK() sometimes fails on Windows 10 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: richedit Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com riched20:editor - test_EN_LINK() sometimes fails on Windows 10: editor.c:6829: Test failed: cursor position set test 12: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 12: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 12: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 12: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 12: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 12: Expected link range [0,31) got [589505315,589505315) editor.c:6829: Test failed: cursor position set test 13: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 13: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 13: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 13: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 13: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 13: Expected link range [0,31) got [589505315,589505315) editor.c:6829: Test failed: cursor position set test 28: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 28: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 28: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 28: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 28: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 28: Expected link range [0,31) got [589505315,589505315) editor.c:6829: Test failed: cursor position set test 29: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 29: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 29: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 29: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 29: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 29: Expected link range [0,31) got [589505315,589505315) editor.c:6829: Test failed: cursor position set test 44: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 44: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 44: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 44: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 44: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 44: Expected link range [0,31) got [589505315,589505315) editor.c:6829: Test failed: cursor position set test 45: Expected hwnd 00000000004E0452 got 2323232323232323 editor.c:6831: Test failed: cursor position set test 45: Expected idFrom 0 got 0x2323232323232323 editor.c:6833: Test failed: cursor position set test 45: Expected msg 0x20 got 0x23232323 editor.c:6837: Test failed: cursor position set test 45: Expected wParam 0 got 0x2323232323232323 editor.c:6845: Test failed: cursor position set test 45: Expected lParam 0x50005 got 0x2323232323232323 editor.c:6848: Test failed: cursor position set test 45: Expected link range [0,31) got [589505315,589505315) https://test.winehq.org/data/patterns.html#riched20:editor The failures always happen in the same iterations which all correspond to WM_CHILD tests. -- 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.

1 3

[Bug 52511] New: Race condition on exit of application
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=52511 Bug ID: 52511 Summary: Race condition on exit of application Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)jonass.user.lysator.liu.se Distribution: --- Created attachment 71812 --> https://bugs.winehq.org/attachment.cgi?id=71812 Inital log. Shows threads waiting. Version 7.0 seems to have introduced an race condition on exit of at least one application. https://appdb.winehq.org/objectManager.php?sClass=version&iId=6602 On exit I get these errors about two thread seeming to wait for each other. See attached log. Repeating infinitely. Tested both with 7.0 and wine-7.1-180-gadda27cdb82 on Xubuntu 20.04.3. -- 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.

1 21

[Bug 53993] New: FL Studio 20.7.2 - Mouse disappears on dropdown menus
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=53993 Bug ID: 53993 Summary: FL Studio 20.7.2 - Mouse disappears on dropdown menus Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: joaonunatingscode(a)gmail.com Distribution: --- Created attachment 73578 --> https://bugs.winehq.org/attachment.cgi?id=73578 GIF showing bug When clicking in a dropdown menu mouse disappears but selection is still shown. When changing from any workspace to the workspace containing FL Studio, the mouse works fine for the same dropdown menu, then the behavior is the same. I've posted this in reddit which got a response saying it might be because FL Studio uses custom mouses styles. System information: OS: Arch Linux x86_64 WM: sway 1.7 (wayland 1.21) Wine: wine-7.20 (staging) FL Studio: v20.7.2 [build 1863] -- 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.

1 1

[Bug 53251] New: d3d10core:d3d10core - test_pipeline_statistics_query() sometimes fails on Windows 10 1909+
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53251 Bug ID: 53251 Summary: d3d10core:d3d10core - test_pipeline_statistics_query() sometimes fails on Windows 10 1909+ Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com d3d10core:d3d10core - test_pipeline_statistics_query() sometimes fails on Windows 10 1909+: d3d10core.c:4780: Test failed: Got unexpected IAVertices count: 0. d3d10core.c:4781: Test failed: Got unexpected IAPrimitives count: 0. d3d10core.c:4782: Test failed: Got unexpected VSInvocations count: 0. d3d10core.c:4785: Test failed: Got unexpected CInvocations count: 0. d3d10core.c:4786: Test failed: Got unexpected CPrimitives count: 0. https://test.winehq.org/data/patterns.html#d3d10core:d3d10core These failures seem to only happen on the TestBot VMs that use the basic 'VGA' driver. However they are pretty rare so it's hard to be sure they cannot happen on the QXL multi-monitor configurations. They are also rare enough to cause false positives. -- 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.

1 3

[Bug 53940] New: I have an app that launches an app, but when that app launches the second app, the second app opens with a black screen.
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53940 Bug ID: 53940 Summary: I have an app that launches an app, but when that app launches the second app, the second app opens with a black screen. Product: Wine Version: 7.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hsehnt(a)q.com Distribution: --- Created attachment 73498 --> https://bugs.winehq.org/attachment.cgi?id=73498 standard out of wine RMS\ Express.exe I have an app that launches an app, but when that app launches the second app, the second app opens with a black window. It doesn't do that in windows. I've recorded the screencast and piped the standard out to blackscreen.txt $ wine RMS\ Express.exe |& tee blackscreen.txt I updated the screencast and blackscreen.txt file. At about 10 seconds into the video I click on the open session (upper right of screen) to launch a VARA HF winlink session. This is still part of the first app (RMS Express). The VARA HF winlink session request spawns a new app called VARA. It is the VARA app that opens with a black window. If I open VARA manually, it opens with a good usable window. It's only a black window when automatically spawned by RMS Express. I don't know how to troubleshoot this. I'm hoping there is enough information in the blackscreen.txt file that can be correlated with the screen capture. -- 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.

1 29

[Bug 53989] New: wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53989 Bug ID: 53989 Summary: wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows: http.c:1603: Test failed: Could not create file: 32 http.c:1605: Test failed: file size = 4294967295 http.c:1613: Test failed: file size = 4294967295 http.c:1617: Test failed: Deleting file returned 1(6) http.c:1623: Test failed: Could not create file: 2 http.c:1625: Test failed: WriteFile failed: 0, 0 http.c:1627: Test failed: CommitUrlCacheEntry failed: 2 http.c:1634: Test failed: HttpSendRequest failed http.c:1639: Test failed: size = 0 http.c:1641: Test failed: incorrect page data: <html><body> <h1>Hello world!</h1> This is a test page for the Wine regression test suite. </body>< See https://test.winehq.org/data/patterns.html#wininet:http Where the first failure causes all the other ones and 32 == ERROR_SHARING_VIOLATION. This failure mode has only happened on w1064v1809, w1064-tsign (21H2) and w1064v21h2 for a total of 8 occurrences between 2022-06-13 and 2022-11-23. This seems like broken Windows behavior so maybe we should retry after a delay and a broken()? -- 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.

1 1

[Bug 53988] New: wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53988 Bug ID: 53988 Summary: wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status. For instance on 2022-11-23 on w1064v1507-32: http.c:5694: Testing InternetReadFileExW with IRF_NO_WAIT flag... http.c:5781: Testing InternetQueryDataAvailable... http.c:376: Test failed: unexpected status 10 (INTERNET_STATUS_RESOLVING_NAME) http.c:376: Test failed: unexpected status 11 (INTERNET_STATUS_NAME_RESOLVED) http.c:376: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:5353: Test failed: expected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) 1 times, received 2 times ... http.c:596: Starting InternetReadFile test with flags 0x10000000 on url http://test.winehq.org/tests/post.php http.c:644: Test failed: expected status 10 (INTERNET_STATUS_RESOLVING_NAME) 0 times, received 1 times http.c:645: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 0 times, received 1 times Or in a slightly different location on 2022-08-19 on w1064v1507-64: http.c:5694: Testing InternetReadFileExW with IRF_NO_WAIT flag... http.c:376: Test failed: unexpected status 10 (INTERNET_STATUS_RESOLVING_NAME) http.c:376: Test failed: unexpected status 11 (INTERNET_STATUS_NAME_RESOLVED) http.c:376: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:5353: Test failed: expected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) 1 times, received 2 times ... http.c:596: Starting InternetReadFile test with flags 0x10000000 on url http://test.winehq.org/tests/post.php http.c:644: Test failed: expected status 10 (INTERNET_STATUS_RESOLVING_NAME) 0 times, received 1 times http.c:645: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 0 times, received 1 times See https://test.winehq.org/data/patterns.html#wininet:http This has only been seen on w1064v1507 and the new w11pro64 VM. So it's not just a quirk of Windows 10 1507 but I don't know what sets these two test configurations apart from the others (if anything). My understanding is that we expect to get these statuses only on the first connection to the server. After that we expect the DNS information and/or server connection to be cached so that these steps are skipped. However: 1. I don't think we should make assumptions on when Windows is allowed to clear its DNS cache or reset its connections. 2. Maybe the connection was actually closed by the server? For instance my understanding is that Apache can be configured to start a new worker process after a number of requests have been served. If that limit is reached while our test runs I believe we may get disconnected and have to reconnect to the new worker process. 3. Or the winehq.org administrator restarted the (web) server on these dates? 3. Or sometimes there are just network glitches. So I think we should allow these statuses as optional pretty much everywhere. -- 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.

1 1