Clipboard format fixtures: virtual_only intermittently fails to publish with ERROR_CLIPBOARD_NOT_OPEN

[btsouth]

Symptom

scripts/test-clipboard-formats.ps1 intermittently fails with the virtual_only
fixture missing. The summary shows six of seven fixtures observed, timed_out: true,
read_failures: 0, and an empty fixture_failures list:

{"event":"summary","expected_fixtures":7,"observed_fixtures":6,"passed_fixtures":6,
 "fixture_failures":[],"read_failures":0,"timed_out":true,"passed":false}

The writer process prints the underlying cause on stderr:

clipboard fixture writer failed: failed to write fixture virtual_only:
Empty clipboard error, code = OSError(1418): Thread does not have a clipboard open.

Error 1418 is ERROR_CLIPBOARD_NOT_OPEN, so this is not ordinary
ERROR_ACCESS_DENIED contention -- set_fixture already retries that ten times.
clipboard_rs successfully opened the clipboard and then found its own handle
gone by the time it called EmptyClipboard.

Suspected cause

virtual_only is written immediately after the two delayed fixtures. The delayed
writer owns a hidden window on the same thread that clipboard_rs writes from.
When the next fixture empties the clipboard, that window receives
WM_RENDERALLFORMATS, whose handler calls OpenClipboard/CloseClipboard on
that same thread. A nested open and close around an in-flight clipboard_rs
write would leave the writer's clipboard closed underneath it, which matches
error 1418 exactly.

The fix is likely to serialize the delayed owner's render against fixture writes,
or to move the delayed writer window onto its own thread, rather than to add more
retries.

Not a regression from #163

Measured by building the probe from main and from the #163 branch and running
each fifteen times on the same machine:

build	failures	fixture
baseline (aa06864)	1 / 15	virtual_only
#163 branch	1 / 15	virtual_only

Both fail the same way, so #163 neither introduces nor fixes this. It is called
out here because #163's clipboard-contention retries are adjacent to it and the
distinction is easy to lose later.

Impact

CI does not run this suite -- it is a local Windows-only script -- so this costs
a re-run rather than a red build. It does undermine the suite's value as evidence:
a single red run currently cannot be read as a capture regression without checking
which fixture went missing and whether read_failures was zero.

docs/CLIPBOARD_RELIABILITY.md documents the flake and points here.

[Vermitrude]

Is this on?

[btsouth]

Yes, this is still open. If you mean you'd like to work on it, say so and I'll assign it to you.

[Vermitrude]

i'd like to work on it

[btsouth]

All yours! Assigned.

[btsouth]

@Vermitrude — found what looks like the mechanism while working on an unrelated clipboard change. Sharing so you do not have to rediscover it.

clipboard-rs 0.2.4 swallows the OpenClipboard failure. In src/platform/win.rs, set() at line 382:

fn set(&self, contents: Vec<ClipboardContent>) -> Result<()> {
    let _clip = ClipboardWin::new_attempts(10)
        .map_err(|code| format!("Open clipboard error, code = {}", code));   // <-- note: no `?`
    let res = clipboard_win::empty();
    if let Err(e) = res {
        return Err(format!("Empty clipboard error, code = {}", e).into());
    }

The map_err result is bound to _clip and discarded — there is no ?. So when OpenClipboard fails all ten attempts, the error never surfaces; execution falls through to clipboard_win::empty(), which then fails with exactly the 1418 ERROR_CLIPBOARD_NOT_OPEN in this issue.

set_image() at line 349 is the one site that gets it right — line 350 ends with )?;. The same missing ? appears in available_formats() (100), clear() (149), get() (244) and set_files() (376).

That explains the parts of the report that look contradictory:

• Why it is not ERROR_ACCESS_DENIED. It is access-denied, at the open. It is masked and resurfaces as 1418 one call later.
• Why set_fixture's ten retries do not help. They retry on code 5, which this path can no longer produce.
• Why read_failures: 0 alongside a missing fixture. get() swallows its open failure too, so a read can report success without ever holding the clipboard. Worth confirming rather than assuming.

On the contention itself: until #192 (open now), Cubby held the clipboard handle across a full multi-megapixel PNG decode on the capture path. If Cubby is running during a fixture run, that is a real multi-second hold on the same machine. That PR moves the decode before the open, so rebasing on it once it lands should reduce how often you can reproduce this — which cuts both ways for debugging.

Possible directions, your call which fits: treat 1418 as contention and retry it alongside code 5; or have the fixture writer open the clipboard itself via clipboard-win and skip clipboard-rs's set() entirely, which is what Cubby's relay path now does; or fix it upstream, since the one-character difference between set() and set_image() is plainly unintentional.

I have not reproduced the failure myself — this is source reading, so please verify before building on it.

[btsouth]

Thanks for offering to help, @Vermitrude. The delayed-writer fix landed in #167. I reran the current probe 50 times on Windows 11 with Cubby running: all 350 fixtures passed, with no read failures or timeouts. Closing this as resolved. Please reopen it if the 1418 failure returns.