fix(desktop): enable arboard Wayland backend so Linux copies reach the Wayland clipboard

[shawnyeager]

Fixes #2896

Root cause: arboard = "3" compiles with default features only (image-data), so the Linux build has no Wayland backend. In a Wayland session every copy lands on the XWayland clipboard; the compositor only mirrors X11 selections while an XWayland window holds focus, and arboard's clipboard client is windowless, so Wayland-native apps read nothing. set_text still returns Ok, which is why the invite dialog shows "Copied" with an empty clipboard.

Fix: enable arboard's wayland-data-control feature. Under Wayland it uses the zwlr-data-control protocol; when WAYLAND_DISPLAY is absent it falls back to X11 as before. The wl-clipboard-rs dependency is target-gated inside arboard, so macOS and Windows builds are unchanged.

Verified: cargo check passes on the desktop crate; wl-clipboard-rs now resolves in the lockfile.

[wpfleger96]

🤖 Agent-authored review.

IMPORTANT — Correctness: the sole commit is missing its Signed-off-by trailer, so the repository-required DCO check fails. Please amend it with git commit --amend --no-edit --signoff and force-push the updated commit.

The implementation itself is appropriately minimal: wayland-data-control activates wl-clipboard-rs only on supported Unix targets, arboard selects that backend when WAYLAND_DISPLAY is present and retains its X11 fallback, and the lockfile matches the feature graph. I found no code defect.

At 0d1203e340adbb0b009501fb7ef9706a1a93bd3f, just desktop-tauri-fmt-check, just desktop-tauri-check, just desktop-tauri-clippy, and just desktop-tauri-test pass (1,629 passed, 14 ignored, plus 3 diagnostic tests). Rust Lint, Semgrep, zizmor, and Desktop E2E Relay also pass in CI; the remaining CI jobs are still running. Requesting changes solely for the required DCO sign-off.

[wpfleger96]

🤖 Agent-authored review.

Verified the root-cause claim and the mechanism at source, not just from the description. The diagnosis is right and the fix is the minimal correct one.

What I confirmed in arboard 3.6.1 (vendored at ~/.cargo/registry/src/index.crates.io-*/arboard-3.6.1):

• wayland-data-control = ["wl-clipboard-rs"] exists, and mod wayland in src/platform/linux/mod.rs is gated on it — so without the feature the Linux build genuinely has no Wayland backend and Clipboard::new() unconditionally returns Self::X11(..). The bug report's diagnosis holds.
• Backend selection (linux/mod.rs, Clipboard::new) does exactly what the description says: if WAYLAND_DISPLAY is set it tries wayland::Clipboard::new(), and on error falls back to X11 with a warn!. X11-only sessions are unaffected.
• wl-clipboard-rs is declared under [target.'cfg(all(unix, not(any(target_os="macos", target_os="android", target_os="emscripten"))))'.dependencies], so the "macOS and Windows unaffected" claim is accurate at the manifest level.

No new system build deps — I checked this specifically because wayland-sys uses pkg-config and wayland-backend uses cc. Neither triggers here: cargo tree --target x86_64-unknown-linux-gnu -e features -p wayland-sys resolves wayland-sys with no features, and its build.rs only probes pkg-config under client/server/cursor/egl. wayland-backend likewise doesn't enable client_system, so libwayland-dev is not required. Empirically confirmed: Desktop Core is green at 0d1203e, and that job compiles the Tauri crate on ubuntu-latest (desktop-tauri-clippy / -check / -test) with the existing apt list.

CI status at 0d1203e: Rust Lint, Desktop Core, Windows Rust, Desktop Build (macOS), Semgrep, zizmor all green.

• DCO Check = FAILURE ("All commits are missing DCO sign-off"). git log -1 on 0d1203e has no Signed-off-by: trailer. This is the only thing gating merge — needs an amend + force-push.
• Desktop Smoke E2E (4) = FAILURE, and it is unrelated to this change. It's tests/e2e/thread-focus-mode.spec.ts:206 toBeInViewport() → "viewport ratio 0" (174 passed, 1 failed after 2 retries). That job never compiles Rust — its steps are pnpm -C desktop build:e2e + Playwright against the mock bridge — so a Cargo.toml/Cargo.lock-only diff cannot influence it. Matches the known scroll-anchor flake bucket.

---

Non-blocking notes

MINOR — the fix narrows the silent-failure class, it doesn't close it. Clipboard::new() falls back to X11 whenever wayland::Clipboard::new() errors, and wayland::Clipboard::new() requires ext-data-control or wlr-data-control from the compositor. Hyprland (the reporter's) is wlroots and exposes zwlr_data_control_manager_v1, so #2896 is genuinely fixed for them. KWin also qualifies — it implements ext_data_control_manager_v1 (KDE/kwin src/wayland/datacontroldevicemanager_v1.cpp). GNOME/Mutter implements neither: GNOME/mutter src/wayland/ has no data-control source file at all. On GNOME Wayland this PR changes nothing, and the original symptom — set_text returns Ok over an empty clipboard — persists. Worth a follow-up issue rather than scope creep here.

MINOR — the fallback is currently invisible. arboard logs that fallback via the log crate (warn! in Clipboard::new), but the Tauri crate installs no log implementation — no log, env_logger, tracing-subscriber, or tauri-plugin-log in desktop/src-tauri/Cargo.toml, and no log::/tracing:: call sites in desktop/src-tauri/src. So when the Wayland handshake fails we get the X11 fallback with zero diagnostic trail, which is precisely the debugging difficulty that made #2896 hard to pin down. Cheap follow-up: wire a log sink, or surface the selected backend once at startup.

MINOR — ClipboardState's app-lifetime caching is inert on the Wayland path. wayland::Clipboard is struct Clipboard {} — a ZST holding no connection; each set_text opens a fresh Wayland connection and copy_multi spawns its own serving thread. The doc comment on ClipboardState ("App-lifetime clipboard ownership keeps copied data available on Linux") describes the X11 backend's semantics and is now only half-true for Linux. Harmless, but the comment will mislead the next reader. Same for release() on RunEvent::Exit.

MINOR — supply-chain surface, and it isn't scanned. The lockfile gains 10 crates (wl-clipboard-rs, wayland-{backend,client,protocols,protocols-wlr,scanner,sys}, tree_magic_mini, downcast-rs, os_pipe) plus a second major nom (8.0.0 alongside 7.1.3). Licenses are all fine — every one is MIT or MIT/Apache-2.0, all inside deny.toml's allow list. But note that nothing enforces that: root Cargo.toml has exclude = ["desktop/src-tauri"], so cargo-deny check never sees these crates, and the Security job was SKIPPED on this PR anyway since desktop/src-tauri/** isn't in the rust paths filter. Pre-existing gap, not this PR's to fix — flagging because this PR is the kind of change that gap is blind to.

---

Verdict: approve on the code. The change is minimal, the mechanism is verified at source rather than assumed, and it's the right fix for the reported platform. Add the DCO sign-off and it's mergeable; the E2E red is an unrelated known flake.

[wpfleger96]

🤖 Agent-authored review.

The blocking feedback is addressed. The amended commit includes Signed-off-by: Shawn Yeager <shawn@shawnyeager.com>, and DCO now passes.

I also verified that 7bd9ea6a0dcec51dba3aa20f15bfc4c9bb36de34 has the exact same tree as the previously reviewed 0d1203e340adbb0b009501fb7ef9706a1a93bd3f, so the prior code assessment and passing local Tauri gates still apply. Approving the current head; the newly triggered CI run is still in progress.