[Bug] Invite dialog "Copy link" reports success but leaves the clipboard empty on Linux/Wayland

[shawnyeager]

Describe the bug
"Copy link" in the community invite dialog reports success — the button flips to the "Copied" check state and the "Invite link copied" toast appears — but nothing lands on the system clipboard. Pasting afterwards yields empty or stale content.

Steps to reproduce

1. Open the community invite dialog (Invite people).
2. In the "Share with a link" section, click Copy link.
3. Button shows "Copied" and the success toast fires.
4. Paste anywhere: the clipboard is empty (or still holds its previous content).

Expected behavior
The minted invite URL is on the clipboard after the success state is shown.

Version and platform

• Buzz version: dev build from main (20bff59)
• OS: Arch Linux, Hyprland (Wayland session)

Logs / additional context
Code path: InviteLinkSection.handleCopy (desktop/src/features/community-members/ui/InviteLinkSection.tsx) → writeTextToClipboard → Tauri copy_text_to_clipboard (desktop/src-tauri/src/commands/media_download.rs) → with_clipboard (desktop/src-tauri/src/commands/clipboard.rs) → arboard::Clipboard::set_text.

Since the UI reaches the "Copied" state, mintInvite and the whole native chain resolve Ok — so arboard returns success while the clipboard stays empty. The app-lifetime ClipboardState already covers the X11 "clipboard dies with the setter" case, which points at the Wayland side:

• If arboard is built without the wayland-data-control feature (or the compositor handshake fails), it falls back to the X11 backend via XWayland. Under Hyprland an X11 clipboard set by a window that doesn't hold XWayland focus doesn't propagate to the Wayland clipboard, so set_text succeeds against a clipboard no Wayland client ever reads.
• Hyprland does support zwlr_data_control_manager_v1, so the data-control backend should work when it's actually compiled in and selected.

Worth verifying which backend arboard picks at runtime in the release build, and whether Cargo.toml's arboard = "3" resolves with wayland-data-control enabled.

[leesalminen]

Confirmed your diagnosis empirically on the same setup (Arch / Hyprland), and it's the first bullet: arboard in the shipped binary has no Wayland backend compiled in at all.

Against the 0.4.26 release binary:

strings buzz-desktop | grep -c zwlr_data_control_manager_v1   ->  0
strings buzz-desktop | grep wl-clipboard-rs                   ->  (nothing)

So it's not a runtime handshake failure — the data-control backend isn't in the build, leaving only X11. Isolating arboard 3.6.1 with default features reproduces the exact split you describe:

arboard set_text            ->  Ok
arboard get_text  (X11)     ->  "BUZZ_ARBOARD_TEST_12345"     present
wl-paste          (Wayland) ->  "Nothing is copied"           absent

The text really does land in the XWayland CLIPBOARD selection — a second arboard process reads it straight back — Hyprland just never propagates it. Worth noting the write also clears the Wayland clipboard, which is why the paste is empty rather than stale.

Rebuilding with features = ["wayland-data-control"]: 15 matches for zwlr_data_control_manager_v1, and wl-paste returns the text.

Two things worth adding to the report: this affects every native copy in the app, not just the invite dialog (copy message, copy pubkey — anything routed through copy_text_to_clipboard), and the app-lifetime ClipboardState you flagged is already correct — with data-control compiled in it gives the backend a live owner to serve from, so no code changes are needed beyond the dependency.

PR up at #2922.