Copyq is delaying and pasting multiple times when I am using Gnome on Ubuntu 20.04.

[alexandreqo]

Every time I paste something using Copyq on Ubuntu 20.04 with Gnome, the Copyq delays and paste the selected text multiple times.
The gif below shows you how to reproduce the problem:

Screencast.2021-08-09.03.11.42.mp4

• Copyq 4.10
• Ubuntu 20.04

[hluk]

Hmm, I cannot view the screencast in the description (it says "file is corrupt").

[yudi-azvd]

This bug happens to me as well (Ubuntu 20.04)

@hluk By the way, this app is awesome 😃

[alexandreqo]

Hmm, I cannot view the screencast in the description (it says "file is corrupt").

It is strange. It seems that some people could see the video.
I short words, Copyq is pasting multiple times and having some lag in ubuntu 20.04.

[hluk]

It is strange. It seems that some people could see the video.

Passing the video URL to a media player works:

mpv 'https://user-images.githubusercontent.com/6320673/128718917-67a8fa1f-caff-481c-a15f-f085a791f4ed.mp4'

[hluk]

It seems that the app gets completely stuck while it simulates Shift+Insert. Could be a bug in the window manager - maybe something to do with the minimize/hide window animation.

You can try increasing wait time before pasting (e.g. 150 milliseconds):

copyq config window_wait_after_raised_ms 150

[yudi-azvd]

filename=$(basename -- "$filename##*.")

filename=$(basename -- "$filename##*.")

filename=$(basename -- "$filename##*.")

filename=$(basename -- "$filename##*.")

It still doesn't work. The above text was copied from CopyQ hitting Enter once. Sometimes it's more duplicates, sometimes less. The CopyQ window quickly minimizes and the target window gets frozen, I can't type anything for a couple of seconds

[alexandreqo]

I discovered an important detail. This error only occurs using Gnome.

[hluk]

You can also try setting window_key_press_time_ms to 0 (but it could cause problem with some apps like Chrome; default value is 50 ms on Linux):

copyq config window_key_press_time_ms 0

[alexandreqo]

You can also try setting window_key_press_time_ms to 0 (but it could cause problem with some apps like Chrome; default value is 50 ms on Linux):

copyq config window_key_press_time_ms 0

I tried it and doesn't work.

[ThaisBarrosAlvim]

I'm also having this problem on Ubuntu 20.04

[akshettrj]

I discovered an important detail. This error only occurs using Gnome.

I am facing this problem on BSPWM running on Arch Linux as well. It experiences some delay and then pastes 10-15 times

[amosbird]

I discovered an important detail. This error only occurs using Gnome.

I am facing this problem on BSPWM running on Arch Linux as well. It experiences some delay and then pastes 10-15 times

Recently I'm seeing the same issue with the same setup (bspwm + archlinux)

[robertstrom]

I am, and have been, seeing this issue in Linux too. It does not happen all the time (not anywhere near all the time) but I just had CopyQ paste something 20 time when I clicked on the text to paste within CopyQ.

NOTE that the last line of the text is supposed to be

sudo systemctl restart pure-ftpd

and that CopyQ immediately starts over again with the first line

#!/bin/bash

making the line read

sudo systemctl restart pure-ftpd#!/bin/bash

I will try the suggested config file modifications.

[cpazaras]

Also confirming this issue on Manjaro Linux with Gnome 42.4 (X11).

Doesn't happen all the time, and the number of times that the text gets pasted is not fixed (might be 3-4 times - might be like 30 times).

[hluk]

I have a possible fix.

You can install the Flatpak image with the fix using the instructions in the latest flathubbot comment at: flathub/com.github.hluk.copyq#45

Can anyone check if pasting works well with the new Flatpak image?

[hluk]

I have released the fix in the new 6.3.1 version.

[alexandreqo]

Unafortely right now, I am unable to test because I am using Linux Mint. So I am not using Gnome. I will try to test it on a machine of a friend.

[ThaisBarrosAlvim]

I've tested but the delay still happening.

[hluk]

I've tested but the delay still happening.

Which app version and OS/desktop-environment? Is this happening with the latest Flatpak?

If this is a bug in CopyQ, the only place I see could cause this is at XTestFakeKeyEvent() or XSync() is called.

I have another possible fix that removes the XSync() call in the middle of simulating key press and release (#2116).

I cannot reproduce this so I would appreciate if someone can test the Flatpak build here: flathub/com.github.hluk.copyq#50

[anvishinc]

Had the same issue. And I am sure the initial bug might have been due to an bug in the code which has been since fixed. But I have found that if you don't set a proper limit for how many entries to save then that causes slight delay too. Additionally if you have set any global shortcut for Ctrl + V that occasionally also causes an delay and problems similar to as described in this issue.

[sirianni]

Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection? This would require the the user to use the normal CTRL-V to actually perform the paste. I realize that would require an extra keypress, but that's better than having data pasted twice.

[hluk]

Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection?

@sirianni Disable "Paste to current window" option in History configuration section in Preferences.

[sirianni]

Thank you! I searched all the preferences and overlooked that section!

…

On Thu, Dec 14, 2023 at 1:31 AM Lukas Holecek ***@***.***> wrote: Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection? @sirianni <https://github.com/sirianni> Disable "Paste to current window" option in History configuration section in Preferences. — Reply to this email directly, view it on GitHub <#1729 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC5C5UPXKXR3R5PM3EHGA3YJKML7AVCNFSM5B2C4PH2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVGUZDENRQGEZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jbericat]

Same problem here (Ubuntu 22.04LTS with XFCE 4.18 on gdm3).

$ copyq --version
CopyQ Clipboard Manager 6.0.1
Qt: 5.15.2
KNotifications: 5.89.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Ubuntu 22.04.4 LTS

I believe I found-out how to fix it (at least that's what worked for me): Disabling the Paste to current window option didn't work at all, BUT the problem disappeared instantly (at least for now) once I renamed my default tab to "clipboard_bak1", created a new one called "&clipboard" and set-up the new one as default in history -> Tab for storing clipboard. For the record, I had more than 5k elements on my original tab lol