https://bugs.winehq.org/show_bug.cgi?id=54852
Bug ID: 54852 Summary: Locking the KDE screen causes comctl32:tooltips to fail systematically Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
Locking the KDE screen causes comctl32:tooltips to fail systematically:
tooltips.c:252: Test failed: 0: Failed to get current tool 0. tooltips.c:259: Test failed: 0: Unexpected hwnd CCCCCCCC. tooltips.c:260: Test failed: 0: Unexpected hinst CCCCCCCC. tooltips.c:261: Test failed: 0: Unexpected uId cccccccc. tooltips.c:262: Test failed: 0: Unexpected lParam cccccccc. [... same errors for iterations 1 to 5...] tooltips.c:504: Test marked todo: Adding the tool to the tooltip succeeded! tooltips.c:1150: Test marked todo: 0: Unexpected ret value 1, size 45, max size 44. tooltips.c:1218: Test failed: TTN_SHOW parent seq: the msg sequence is not complete: expected 0000 - actual 004e v6util.h:92: created cc6.manifest [... same errors again ...]
See https://test.winehq.org/data/patterns.html#comctl32:tooltips
Only my development desktop runs the Wine tests in KDE and I normally avoid locking the screen when doing so. But it is quite remarkable that none of the other comctl32 tests has any issue in that scenario, and that out of all the Wine tests only two others have extra failures (user32:input and user32:win).
Also the failures are not unique to this case: * The test_customdraw() failures also happen on Windows, but only one at a time (bug 54580). * The test_TTN_SHOW() also happen randomly in Wine the rest of the time (bug 54581).
Given that these failures are usually quite hard to reproduce, locking the KDE screen may make them easier to debug, assuming this case does not involve a totally different code path.