https://bugs.winehq.org/show_bug.cgi?id=54517
Bug ID: 54517 Summary: riched20:editor - KDE? Clipboard interference causes test_EM_SETUNDOLIMIT() failures Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: richedit Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
riched20:editor - KDE? Clipboard interference causes test_EM_SETUNDOLIMIT() failures:
editor.c:3667: Test failed: EM_SETUNDOLIMIT didn't allow the first undo with UNDOLIMIT set to 2 editor.c:3670: Test failed: EM_SETUNDOLIMIT didn't allow a second undo with UNDOLIMIT set to 2
See https://test.winehq.org/data/patterns.html#riched20:editor
These failures mostly happen on my desktop, fg-deb64, though they did happen a few times on on master and lastestmaster (sic) too (latestmaster did not have that issue). * My desktop is Debian 11 + KDE. * master and lastestmaster are Linux Mint 21 (desktop environment unknown)
On my desktop, whenever Wine modifies the clipboard, some non-Wine process accesses it and sometimes causes the clipboard content to be lost. Whether that has an impact on the tests depends on whether the test is done with the clipboard content by the time that access happens, i.e. there is a race condition.
test_EM_SETUNDOLIMIT() does multiple pastes in a row (101 + 3), each of which accesses the clipboard, which leaves time for that other process to cause the clipboard content to be lost. This results in some pastes not happening so that there are fewer pastes to undo than expected. Hence the failures above.
The test could be modified to check the length of the text field as a way to verify that it got the expected number of successful pastes. If not, it could either limit undos to however many pastes succeeded, or redo a copy plus more pastes to reach the target number.
But I don't remember losing the clipboard content outside of Wine. Of course, unlike Wine's tests I never perform hundreds of copy/pastes per second so maybe that's why. Anyway, there may be something wrong in Wine and then fixing that would be a better approach.
Or it may be a bug in some other component on my desktop that mishandles the clipboard.
Also, even if the clipboard content is not lost, the WM_PASTE handling does a simple OpenClipboard() which would fail if winex11 is already accessing it to handle a query from some other process in the system. That seems too fragile and would also cause missing undos. I don't know how Windows behaves in that case though : Does the WM_PASTE simply fail? Is the OpenClipboard() operation repeated indefinitely? Just a few times?