deskflow is a KVM-over-network tool — share one keyboard and mouse across multiple computers. it works great until you copy something to the clipboard, at which point it occasionally crashes and disconnects.

the bug

on windows, OpenClipboard() is a global mutex. only one process can have it open at a time. if another app (rdpclip.exe is a frequent offender) has the clipboard open when deskflow tries to access it, the call fails immediately. no retry, no backoff, just failure.

deskflow’s response to this failure was to try to send empty clipboard data, which cascaded into a protocol error, which disconnected the client. the fix was +23 lines:

layer 1: retry loop in the clipboard code — 5 attempts, 15ms between tries layer 2: guard against sending empty clipboard data (skip if empty)
layer 3: guard in the server to ignore empty clipboard updates

everyone does this

researching the fix, i found that chromium has the exact same retry loop in ScopedClipboard::Acquire() — 5 retries, 5ms sleep. the code comment mentions rdpclip.exe by name. .NET’s Clipboard.SetDataObject() takes explicit retry count and delay parameters. firefox sidesteps the whole thing by using OLE clipboard APIs instead.

and on macOS? NSPasteboard uses a daemon with message passing. “clipboard is busy” isn’t a state that exists. linux/X11 uses a selection protocol. windows is the only platform where clipboard access is a blocking exclusive lock that can fail.

submitted a PR to deskflow with the fix. clean release build, matches industry standard practice, +23/-6 lines.

the best bugs are the ones where your fix turns out to be the same thing chromium already does.