fix(clipboard): stop caching denied clipboard reads on Win32 (backport #24357) - #24449

GitHub Issue: tracked internally — no public issue to link.

PR Type:

🐞 Bugfix

What changed? 🚀

Current behavior. Run N instances of a Skia Win32 app, copy text in any one of them, and only one instance can paste. In the other N−1, Clipboard.GetContent().Contains(Text) returns false, TextBox.CanPasteClipboardContent is false, and the Paste item vanishes from the context menu — until the clipboard changes again, when a different instance wins and a different set breaks.

Cause. OpenClipboard is a global exclusive lock with exactly one winner, and it is deniable. Win32ClipboardExtension took that lock with a single attempt and no retry, materialised every format under it, then cached the result — successes and failures alike — until the next WM_CLIPBOARDUPDATE.

Because AddClipboardFormatListener broadcasts WM_CLIPBOARDUPDATE to every listener at once, all N instances race for the lock on the same tick. One wins; the rest get ERROR_ACCESS_DENIED, which the old code could not distinguish from an empty clipboard, and then cached that empty DataPackage. Three compounding defects: a denied read looked like an empty one, the failure was cached, and the read ran synchronously from WndProc.

This is not only a multi-instance bug — with no competitor at all, a single un-retried OpenClipboard still failed 3–13 % of the time on an idle desktop.

Availability no longer takes the lock

• Probe the known formats with IsClipboardFormatAvailable, which is documented lock-free and measured 100 % correct while another process holds the lock — including the Excel-style never-rendered delay-render case, where it answers without triggering a render.
• Then make one non-blocking EnumClipboardFormats attempt for full fidelity, so app-specific format names still surface. If that attempt is denied, the package is still correct for every format Uno can decode and is simply not cached — the next call retries. Retry across calls, never inside one, so nothing on the paste-enablement path can block.
• Key the cache on GetClipboardSequenceNumber (also lock-free) rather than on WM_CLIPBOARDUPDATE, so a cached package can never outlive the clipboard generation it was built from. Verified that the sequence number bumps on EmptyClipboard/SetClipboardData and is visible to other processes while the clipboard is still held.
• A jittered warm-up after WM_CLIPBOARDUPDATE (~60/150/400 ms) fills the complete list in the background. The jitter is not cosmetic: processes woken by one broadcast back off in lockstep and collide again without it.

Payloads are fetched lazily, on demand

Via SetDataProvider, one format at a time, awaiting the lock instead of sleeping on it. This also fixes a pre-existing use-after-free: the old deferred providers captured an HGLOBAL from GetClipboardData and GlobalLocked it inside the callback — i.e. after CloseClipboard, when the clipboard-owned handle is no longer valid. Providers now re-fetch by format id and verify the sequence number first.

Writes stop holding the lock across arbitrary work

SetContent resolves all payloads before opening the clipboard, so it no longer pumps the event loop — dispatching arbitrary UI work, and possibly a re-entrant WM_CLIPBOARDUPDATE — while holding the global lock. Eager materialisation of 21 delay-rendered formats measured 976 ms, during which every other application's clipboard write fails.

SetContent and Clear retry the open 10 × 100 ms (WPF's cadence, shared by its OleRetryCount/OleRetryDelay) and now check that they actually hold the lock. Previously ClipboardDisposable logged the denial and continued with _shouldClose == false, so SetContent issued every SetClipboardData against a clipboard it had never opened, and Clear silently no-oped.

The retry budget is deliberately split: one cheap attempt on the read hot path, the full budget only on payload fetch / write. A 10 × 100 ms loop inside GetContent() would block the dispatcher for up to 1 s per call, per TextBox, on every clipboard change — putting CanPasteClipboardContent back on a global exclusive lock.

Measured

8 instances × 3 copies, then 12 × 5, driving a real Uno app and publishing from a third-party writer (PowerShell Set-Clipboard):

87.5 % is exactly (N−1)/N. Format fidelity is preserved, not just paste: after the fix every instance reports the complete list including DataObject and Ole Private Data — app-specific names with no table entry, learnable only from EnumClipboardFormats.

Chose user32 over OLE, deliberately

OleGetClipboard does give lock-free enumeration, which user32 cannot. But measurement showed its proxy.GetData payload path is 0 % against raw-published content, so an OLE rewrite would have needed the same retry logic and would not have fixed this bug.

The drag/drop boundary, and what did get cleaned up

Drop's decode path is deliberately not merged into the clipboard's: ReadContentIntoPackage and drop's two decoder bypasses still use the old eager path, so a clipboard fix cannot regress drop. Those readers now live in their own partial, Win32ClipboardExtension.DragDrop.cs, so the boundary is visible in the file layout instead of only in a comment.

The one thing that was unified is the pure pixel work: a single ConvertDibToBmp(void* dib, uint dibSize) now serves both paths, since the DIB→BMP header rewrite has nothing to do with where the handle came from. That conversion is derived from SDL, so this also adds the corresponding zlib-license notice to THIRD-PARTY-NOTICES.md. The remaining duplication — GetText ×2 and drop's decoder dispatch — is left for a follow-up.

Commits

PR Checklist ✅

• 🧪 Added Runtime tests, UI tests, or a manual test sample (for bug fixes / features, if applicable)
• 📚 Docs have been added/updated following the documentation template (for bug fixes / features)
• 🖼️ Validated PR Screenshots Compare Test Run results.
• ❗ Contains NO breaking changes
• 👀 Reviewed 2 other open pull requests (optional but appreciated!)

Given_Clipboard.Win32.cs asserts the contention is real before asserting the fix: a background thread takes OpenClipboard from a message-only window and holds it, and the test fails unless OpenClipboard is genuinely denied with ERROR_ACCESS_DENIED. Confirmed to discriminate — reverting only the clipboard file makes it fail with the bug's exact log signature.

🤖 Generated with Claude Code