CopyQ Freezes When Accessing Own Clipboard Data in Wayland

[jwangac]

Describe the bug

When using CopyQ in Wayland (without XWayland), the application freezes for about 1 second when attempting to paste an item immediately after selecting it in the CopyQ interface. This issue appears to be related to two recent commits related to accessing the clipboard in Wayland: c55fcb2c (Wayland: Fix accessing own clipboard) and bfe76c16 (Wayland: Fix crash when getting own clipboard data).

To Reproduce

1. Run CopyQ server
2. Copy some text to clipboard from any application
3. Paste the text anywhere - this works fine, no delay
4. Run copyq show to open the GUI
5. Select the first item (the one just copied)
6. Immediately attempt to paste it (within 1 second) - CopyQ freezes for about 1 second
7. If you wait longer than 1 second after selecting the item before pasting, no freeze occurs

Expected behavior

Selecting an item from CopyQ and immediately pasting it should work without any delay or freeze.

Version, OS and Environment

• CopyQ master branch (latest commit before bisect)
• OS: Debian GNU/Linux 13 (trixie) x86_64
• Kernel: Linux 6.12.38+deb13-amd64
• WM: Sway 1.10.1 (Wayland)
• Pure Wayland environment (XWayland disabled)

Additional context

Bisecting the issue identified two problematic commits:

• c55fcb2c (Wayland: Fix accessing own clipboard)
• bfe76c16 (Wayland: Fix crash when getting own clipboard data)

Reverting these commits fixes the issue completely - selecting and pasting works fluently with no warnings or freezes.

During the freeze, the following warnings appear in the log:

Warning: [default] QtWarning: DataControlOffer: timeout reading from pipe
Warning: ELAPSED 1010 ms accessing [data:text/plain]
Warning: ELAPSED 1012 ms accessing [UTF8:text/plain]
Warning: [default] QtWarning: DataControlOffer: timeout reading from pipe
Warning: ELAPSED 1011 ms accessing [:imageData]

[hluk]

Yeah, I noticed the same thing in some cases. Unfortunately, there is no solution for this, the Wayland clipboard management is a mess.

Some details: CopyQ uses code from KGuiAddons. The problem is that it uses unix pipes to pass the data in the same process/thread which gets stuck if data is sent from the single GUI thread.

I solved this before using multithreading, but it caused some rare crashes (some parent objects were deleted during the data transfer).

[hluk]

6. Immediately attempt to paste it (within 1 second) - CopyQ freezes for about 1 second

7. If you wait longer than 1 second after selecting the item before pasting, no freeze occurs

I cannot reproduce this specific case. It likely does not freeze after a short interval, because the clipboard is passed to a separate process after the copy operation (another workaround).

[jwangac]

I noticed that Sway 1.11 has added support for ext-data-control-v1 as an alternative protocol for clipboard managers, and I hope this resolves the problem.

Thanks for your reply. I understand the situation now. I'll continue building CopyQ with the two commits revoked. Thank you. Should I close this issue, or would you prefer to leave it open?

[hluk]

I noticed that Sway 1.11 has added support for ext-data-control-v1 as an alternative protocol for clipboard managers, and I hope this resolves the problem.

I don't see this can be fixed with the new protocol - it still seems to rely on passing through pipes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/ext-data-control/ext-data-control-v1.xml#L244

Should I close this issue, or would you prefer to leave it open?

Feel free to leave this open.