hluk / CopyQ

Clipboard manager with advanced features
GNU General Public License v3.0
8.26k stars 430 forks source link

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

Open alexandreqo opened 2 years ago

alexandreqo commented 2 years ago

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:

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

hluk commented 2 years ago

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

yudi-azvd commented 2 years ago

This bug happens to me as well (Ubuntu 20.04)

@hluk By the way, this app is awesome 😃

alexandreqo commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

hluk commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I'm also having this problem on Ubuntu 20.04

akshettrj commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

image

cpazaras commented 1 year ago

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 commented 1 year ago

I have a possible fix.

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

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

hluk commented 1 year ago

I have released the fix in the new 6.3.1 version.

alexandreqo commented 1 year ago

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 commented 1 year ago

I've tested but the delay still happening.

hluk commented 1 year ago

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: https://github.com/flathub/com.github.hluk.copyq/pull/50

anvishinc commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 https://github.com/hluk/CopyQ/issues/1729#issuecomment-1855226012, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC5C5UPXKXR3R5PM3EHGA3YJKML7AVCNFSM5B2C4PH2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVGUZDENRQGEZA . You are receiving this because you were mentioned.Message ID: @.***>

jbericat commented 4 weeks ago

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