[Bug 54517] New: riched20:editor - KDE? Clipboard interference causes test_EM_SETUNDOLIMIT() failures
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?
https://bugs.winehq.org/show_bug.cgi?id=54517
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #1 from Eric Pouech eric.pouech@gmail.com --- Created attachment 74057 --> https://bugs.winehq.org/attachment.cgi?id=74057 tentative patch
Hi François,
does the attached patch help in your testings?
a summary of some investigations: - I've never experienced a loss of clipboard content, but rather another process accessing the clipboard at the same time as the test; letting OpenClipboard, or WM_PASTE, or... not to perform any action. - on Huw's suggestion, the EM_(G[S)ETMODIFY messages help detect if eg. a paste operation succeeded (that's what's done in send_message() helper) - at the time of submitting the (previous) change, I didn't include the undo tests (as I didn't look at how success vs pushing a new undo op on the stack would perform); but I did look at and confirmed that WM_PASTE success did set modify flag (and failure, don't change it).
So if we assume that MS did the things right, the undo op should only be pushed in case of success ; and the attached patch should help (in theory <g>).
A+
https://bugs.winehq.org/show_bug.cgi?id=54517
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
--- Comment #2 from François Gouget fgouget@codeweavers.com --- That's nice!
It does not fix the failures but it provides interesting details:
editor.c:3691: initial text len=1 str="x" Paste success on try 0 ... 33 more repeats editor.c:3700: Test failed: Failed to paste clipboard content editor.c:1445: 00010030 (__wine_clipboard_manager) opened the clipboard ... editor.c:3703: 100 paste len=68 str="x\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\rx\r"
So all the failures come after the initial paste successes. Either the clipboard gets emptied at some point; Wine's clipboard manager keeps it open for a very long time; or it forgets to close the clipboard but then I'd expect more tests to fail (I don't (always) see failures from the tests after test_EM_SETUNDOLIMIT() and they do pastes too).
https://bugs.winehq.org/show_bug.cgi?id=54517
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- __wine_clipboard_manager is likely forwarding the clipboard management to the X11 clipboard, where all your desktop apps might come into play (and keep the clipboard open for quite some time or not squashing several update events into one)
some ways forward: - could you bump the number of retries and wait time in send_paste to see if it improves the situation? - do could also isolate the tests from your desktop (using xvfb or xnest or ...)?
https://bugs.winehq.org/show_bug.cgi?id=54517
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
WineHQ Bugzilla