[Bug 51234] New: user32:clipboard test_ClipboardOwner() has a race condition with clipboard managers

[WineHQ Bugzilla]

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

Bug ID: 51234
           Summary: user32:clipboard test_ClipboardOwner() has a race
                    condition with clipboard managers
           Product: Wine
           Version: 6.8
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: user32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

test_ClipboardOwner() has a race condition with clipboard managers that causes
this set of failures:

clipboard.c:404: Test failed: SetClipboardData succeeded
clipboard.c:406: Test failed: wrong error 3735928559
clipboard.c:407: Test failed: SetClipboardData succeeded

Fortunately(?) this failure is pretty rare.

What happens is this:

* test_ClipboardOwner() does this:
  OpenClibpoard(NULL)
  EmptyClipboard() // take ownership
  CloseClipboard()

* Then the clipboard manager starts checking the content of the clipboard:
  OpenClipboard(manager_hwnd)
  ...

* And then the next test_ClipboardOwner() test happens:
  SetClipboardData(CF_WAVE, ...)
  ok(GetLastError() == ERROR_CLIPBOARD_NOT_OPEN, ...)
  ok(!IsClipboardFormatAvailable(CF_WAVE), ...

Because test_ClipboardOwner() opened the clipboard with a NULL windows handle,
EmptyClipboard() used that as the clipboard owner. But when the owner is NULL a
process can place data in the clipboard as long as any process opened it. This
is actually the whole point of the run_process("set_clipboard_data 4") test.

So the problem is that user32:clipboard assumes that no other process is going
to open the clipboard after it called CloseClipboard(). Yet that's precisely
when clipboard manager would receive a WM_CLIPBOARDUPDATE message and open it.