[Bug 55277] New: riched20:editor - test_WM_PASTE() sometimes fails Ctrl+C/V or undo/redo on Windows and Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55277

Bug ID: 55277
           Summary: riched20:editor - test_WM_PASTE() sometimes fails
                    Ctrl+C/V or undo/redo on Windows and Wine
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: richedit
          Assignee: [e-mail]
          Reporter: [e-mail]

riched20:editor - test_WM_PASTE() sometimes fails Ctrl+C/V or undo/redo on
Windows and Wine:

editor.c:5536: Test failed: test paste: strcmp = 1, text='testing paste
'

or

editor.c:5628: Test failed: test paste: strcmp = -1
editor.c:5640: Test failed: test paste: strcmp = 1
editor.c:5664: Test failed: test paste: strcmp = 1, actual = 'testing paste
'

or

editor.c:5678: Test failed: test paste: strcmp = -1, actual = 'paste'

See https://test.winehq.org/data/patterns.html#riched20:editor

[Bug 55277] riched20:editor - test_WM_PASTE() sometimes fails Ctrl+C/V or undo/redo on Windows and Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55277

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |source, testcase

[Bug 55277] riched20:editor - test_WM_PASTE() sometimes fails Ctrl+C/V or undo/redo on Windows and Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55277

--- Comment #1 from François Gouget  ---
The messages have been changed to make them more informative.
One of the new failure messages is:

editor.c:5609: Test failed: 1:Ctrl-V "testing paste\r\n"

This means the paste had no effect. Either because there is a delay before the
paste appears in the text field (doubtful), or because the clipboard was empty
which would match known clipboard issues.

Based on other tests, some process seems to open the clipboard and, because
only one process can open it at a time, that prevents our tests from setting
the clipboard content (even through Ctrl+C) so that the clipboard is empty when
we paste and thus the content of the text field does not change.

While the mechanism is known I don't see how Windows could have such a bug.
Wouldn't the forums be filled with people complaining that copy/paste keeps
glitching? I suspect the issue only happens if the copy and paste happen in
close succession: something watches the clipboard, and within milliseconds
opens and closes the clipboard to check its content. In normal usage the paste
would only come hundreds of milliseconds after that and thus would succeed.

So this looks like an unavoidable race condition which fortunately does not
cause systematic failures (although on some platforms like KDE it's pretty
bad). So maybe this would be a good case for retrying the test a couple of
times. At least on Windows.