[Bug 57926] New: wine-mono wpfclipboard test can fail if a clipboard manager is running

[WineHQ Bugzilla]

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

Bug ID: 57926
           Summary: wine-mono wpfclipboard test can fail if a clipboard
                    manager is running
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ole32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

This is an odd one. I've been seeing random failures in the wpfclipboard test
(https://gitlab.winehq.org/mono/wine-mono/-/blob/main/tools/tests/wpfclipboar...).
This is caused by fcitx requesting the clipboard at a bad time, presumably
after it changes so it can track the history. I tried enabling clipboard
history on Windows, and it didn't break the same test, so presumably this is a
Wine bug of some variety.

An ole,clipboard log first shows FCITX requesting the clipboard contents:
00a4:trace:clipboard:X11DRV_SelectionRequest got request on 5200003 for
selection "CLIPBOARD" target "UTF8_STRING" win 1600000 prop
"FCITX_X11_SEL_CLIPBOARD"
00a4:trace:clipboard:NtUserOpenClipboard 0x10030
00a4:trace:clipboard:NtUserGetClipboardData CF_UNICODETEXT sending
WM_RENDERFORMAT to 0x10058

followed by WPF repeatedly trying to call OleFlushClipboard like this:
0140:trace:ole:OleFlushClipboard ()
0140:trace:clipboard:NtUserOpenClipboard 0x10058
(WPF will retry this in a loop, 10 times with 0.1 second delay, until it
succeeds:
https://gitlab.winehq.org/mono/wpf/-/blob/wine-mono/src/Microsoft.DotNet.Wpf...)

And finally an exception:
[ERROR] FATAL UNHANDLED EXCEPTION: System.Runtime.InteropServices.COMException
(0x800401D0)
  at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR (System.Int32
errorCode, System.IntPtr errorInfo) [0x0000b] in
<9023c5f6a7ee423aa752c291dcce5a37>:0 
  at MS.Internal.SecurityHelper.ThrowExceptionForHR (System.Int32 hr) [0x00008]
in <a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.Flush () [0x0002c] in
<a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.CriticalSetDataObject (System.Object data,
System.Boolean copy) [0x000a9] in <a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.SetDataObject (System.Object data, System.Boolean
copy) [0x00001] in <a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.SetDataInternal (System.String format,
System.Object data) [0x00025] in <a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.SetText (System.String text,
System.Windows.TextDataFormat format) [0x0003f] in
<a958f5aec4f044f89438543f2bcdc7c8>:0 
  at System.Windows.Clipboard.SetText (System.String text) [0x00015] in
<a958f5aec4f044f89438543f2bcdc7c8>:0

This error code is CLIPBRD_E_CANT_OPEN, according to a quick search.

Importantly, WPF's loop doesn't handle window messages. The clipboard is open
because explorer is waiting for WPF to respond to WM_RENDERFORMAT, but WPF
can't do that because it's in the Flush loop.

I'm not sure how this is supposed to work. The Flush loop in WPF is the same in
modern .NET, so that can be assumed to work on Windows without running a
message loop. (We could theoretically work around it in Wine Mono, but that
wouldn't help with modern .NET. I also don't expect this failure mode to be
common in practice.)