Skip to content

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

New issue
New issue
Closed
#2904
#3513
Closed
[Bug] Invite dialog "Copy link" reports success but leaves the clipboard empty on Linux/Wayland#2896
#2904
#3513

Description

@shawnyeager
shawnyeager
opened on Jul 25, 2026

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.

Activity

  1. shawnyeager
    added a commit that references this issue on Jul 25, 2026

    fix(desktop): enable arboard Wayland backend so Linux copies reach th…

    7bd9ea6

  2. leesalminen commented on Jul 26, 2026

    @leesalminen
    leesalminen
    on Jul 26, 2026
    Contributor

    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.

  3. wpfleger96
    closed this as completedin #2904on Jul 26, 2026
  4. wpfleger96
    added a commit that references this issue on Jul 26, 2026

    fix(desktop): enable arboard Wayland backend so Linux copies reach th…

    ab7aa8b
  5. JoeJoeflyn
    added a commit that references this issue on Jul 29, 2026

    fix(desktop): try navigator.clipboard before arboard for npub/nsec copy

    205d6f4
  6. BradGroux
    added a commit that references this issue on Aug 23, 2026

    fix(desktop): enable arboard Wayland backend so Linux copies reach th…

    3f2f396
  7. richardokonicha
    added a commit that references this issue on Oct 23, 2026

    fix(desktop): enable arboard Wayland backend so Linux copies reach th…

    d3b8c1c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions