Skip to content

fix: use GET_PRIVATE_LINK socket command for Wayland clipboard support#12

Open
DeepDiver1975 wants to merge 1 commit into
masterfrom
fix/wayland-clipboard-get-private-link
Open

fix: use GET_PRIVATE_LINK socket command for Wayland clipboard support#12
DeepDiver1975 wants to merge 1 commit into
masterfrom
fix/wayland-clipboard-get-private-link

Conversation

@DeepDiver1975

Copy link
Copy Markdown
Member

Problem

On native Wayland sessions the ownCloud daemon has no compositor surface, so
QClipboard::setText() is silently dropped by the compositor. Copy private link to
clipboard
never works on Wayland.

Solution

When the session is Wayland, the extension sends GET_PRIVATE_LINK:<file> to the client
(a new socket command added in owncloud/client) and waits for PRIVATE_LINK:<url>. It
then writes to the clipboard via GTK from within the Nautilus process, which does own an
active Wayland surface.

Falls back to the original COPY_PRIVATE_LINK path on X11 sessions and when the client
version predates the new command (timeout → fall-through).

What changed vs PR #11

  • No sqlite3/sync journal access
  • No config file parsing
  • Extension only uses the public socket API — no client internals

Requires: owncloud/client PR for GET_PRIVATE_LINK command.

Testing

  • Ubuntu 24.04 LTS, Nautilus 46, native Wayland (GNOME): right-click synced file →
    "Copy private link to clipboard" → clipboard contains the URL ✓
  • X11 session: existing behaviour unchanged ✓
  • Old client (no GET_PRIVATE_LINK): times out, falls through to COPY_PRIVATE_LINK ✓

On Wayland, the ownCloud daemon has no compositor surface and cannot
write to the clipboard via Qt. Intercept COPY_PRIVATE_LINK on Wayland,
request the URL back from the client via the new GET_PRIVATE_LINK
command, and write the clipboard via GTK from within Nautilus (which
owns a live Wayland surface).

Falls back to the original COPY_PRIVATE_LINK path on non-Wayland
sessions and when the client does not support GET_PRIVATE_LINK.

Closes: #11

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com>
@DeepDiver1975 DeepDiver1975 force-pushed the fix/wayland-clipboard-get-private-link branch from 907ce34 to db878eb Compare May 11, 2026 20:59

@dj4oC dj4oC left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Companion to the Dolphin extension's Wayland clipboard fix: on Wayland, context_menu_action intercepts COPY_PRIVATE_LINK, sends GET_PRIVATE_LINK:<file>, polls for up to 0.5s for a PRIVATE_LINK: reply, and writes it to the clipboard via GTK3/GTK4 (versioned correctly), falling back to the original socket command on timeout or GTK failure.

Findings

Memory safety: Python — no manual memory management; the GTK clipboard write is wrapped in a broad try/except, which is appropriate here.

Stability/UX concern: _request_private_link polls synchronously inside context_menu_action, briefly blocking the Nautilus extension's calling thread for up to 0.5s. Same category of concern as the Dolphin companion PR, and the timeout (0.5s here vs. 1s in the Dolphin PR) is inconsistent between the two extensions for what should be the same UX.

Cross-repo dependency risk (blocking): Depends on GET_PRIVATE_LINK, added in owncloud/client PR #12535, which this same automated review flagged with a stability: Block finding (use-after-free risk if the socket disconnects before the async reply arrives). Recommend holding this PR until that's fixed upstream.

Platform API: GTK3/GTK4 dual-path clipboard handling is correctly version-gated.

REUSE: Additive changes to an existing licensed file; no new files.

Verdict

Changes requested (pending the upstream client-side fix)

🤖 Automated review by Claude Code (memory-safety · platform-API · REUSE)


Generated by Claude Code

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants