The worker's closure named loader.cb, and a closure moves only the fields it names, so
the worker's window clone was dropped when TextClipboard::new returned. A worker held
by an owner that never answers could then outlive the window. The closure now calls
Loader::load, which moves the whole Loader.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
smithay-clipboard's load() waits for the selection owner's data with no limit, and
Paste and the "is the clipboard still ours" check read on the UI thread, so an owner
that never sends its data froze the window. Reads now run on a worker thread with a
second clipboard on the window's connection and are waited for 2 s at most. While a
read that timed out is unanswered, later reads return at once instead of queueing
behind it, and its late answer is dropped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Where arboard can't open (GNOME has no data-control protocol, and the Flatpak on a
Wayland session has no X11), Copy and Paste use the compositor's core data-device
protocol on the window's own connection through smithay-clipboard, already in the
build through egui-winit: text only, a copy's text or its SVG markup. A bitmap-only
copy reports that this clipboard carries text only and leaves it as it was.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Flatpak on GNOME has no X11 (fallback-x11 on a Wayland session) and GNOME offers
no data-control protocol, so arboard::Clipboard::new() failed every time. The handle
was kept only on success, so the background Paste check reconnected to the compositor
and logged a warning every 250 ms: 267k warnings in 18 h, the 16 MB log full in 3 h.
- A clipboard that can't be opened is tried again after 1 s, doubling to a minute.
A Copy or Paste of the user's retries at most once a second.
- The outage is logged once (WARN) and its end once (INFO), across the UI's and the
background check's handles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
