Bug 417590 - With MaxClipItems=1 NoEmptyClipboard=false, the second time you copy text after emptying the clipboard, you need to invoke "copy" twice
Summary: With MaxClipItems=1 NoEmptyClipboard=false, the second time you copy text aft...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard (show other bugs)
Version: 5.23.5
Platform: Archlinux Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 417729 418178 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-02-13 19:19 UTC by Stefano Milani
Modified: 2022-09-21 07:22 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Recording of tests within VM. Host: Fedora 30. Guest: Neon Testing, 5.18.1 (2.30 MB, video/x-matroska)
2020-02-22 14:28 UTC, tagwerk19
Details
Recording of tests within VM. Host: Fedora 31. Guest: Neon Testing, 5.18.1 (2.62 MB, video/x-matroska)
2020-02-22 14:30 UTC, tagwerk19
Details
Recording of the bug on KDE Neon with Plasma 5.25.2 (2.67 MB, video/x-matroska)
2022-07-06 06:21 UTC, Jakub Kuczys
Details
Recording of the bug on openSUSE Tumbleweed with Plasma 5.25.2 (3.51 MB, video/mp4)
2022-07-07 01:19 UTC, Jakub Kuczys
Details
Recording of the bug within a VM running Manjaro with Plasma 5.25.2 (2.31 MB, video/x-matroska)
2022-07-07 21:54 UTC, Jakub Kuczys
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefano Milani 2020-02-13 19:19:18 UTC
SUMMARY


STEPS TO REPRODUCE
1. open kinfocenter
2. click copy to clipboard in English
3. content is not paste
4. click again copy to clipboard in English
5. content are pasted

OBSERVED RESULT
content is not pasted (is needed to double click copy to clipboard in English to copy them)

EXPECTED RESULT
content is pasted after first click

Operating System: Arch Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Kernel Version: 5.5.3-arch1-1
OS Type: 64-bit
Processors: 4 × Intel® Celeron® CPU N3450 @ 1.10GHz
Memory: 5,7 GiB
Comment 1 jkhsjdhjs 2020-02-14 07:09:11 UTC
Same issue here, but not only with kinfocenter.
When copying something to the clipboard with xsel, I also have to do it twice.
See the following example:

$ xsel -bc                 # clear cliboard
$ xsel -bo                 # verify clipboard is empty
$ echo "test" | xsel -ib   # copy "test" to CLIPBOARD
$ xsel -bo                 # print contents of CLIPBOARD
$ echo "test" | xsel -ib   # try again
$ xsel -bo
test
$ echo "test2" | xsel -ib  # copy something different
$ xsel -bo                 # CLIPBOARD has only been cleared
$ echo "test2" | xsel -ib
$ xsel -bo
test2

Copying text from other applications like konsole or firefox also doesn't work sometimes.

Running Arch Linux with KDE Plasma 5.18, it worked fine before the update to 5.18.
Comment 2 Harald Sitter 2020-02-14 09:32:33 UTC
Does the regular copy to clipboard button work reliably?
Comment 3 jkhsjdhjs 2020-02-14 09:41:06 UTC
I guess you're referring to the copy button in the context menu when right-clicking files or selected text?

For files, I have to copy a file twice so I'm able to paste it.
When cutting a file, I also have cut it twice for it to become semi-transparent and to be able to paste it in a different location.

I have to copy text twice most of the times, sometimes it works, but most of the times it doesn't.
Comment 4 jkhsjdhjs 2020-02-14 09:46:10 UTC
(In reply to Harald Sitter from comment #2)
> Does the regular copy to clipboard button work reliably?

Ah, you were referring to the regular copy to clipboard button in kinfocenter.
That one doesn't work reliably either (at least for me).
Comment 5 Harald Sitter 2020-02-14 09:49:20 UTC
Yep.

Your answer about files tells me much the same thing though. Something seems to be wrong with your klipper (the clipboard manager) in general. That's why also copying files doesn't work the first time.

Moving bug to klipper product.
Comment 6 jkhsjdhjs 2020-02-14 10:05:54 UTC
Just found a workaround: In the klipper configuration enable "Prevent empty clipboard".
Comment 7 Michał Dybczak 2020-02-15 10:12:10 UTC
I can't replicate it on Manjaro Unstable. Info is copied after one click as it should.


Operating System: Manjaro Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Kernel Version: 5.5.3-2-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 7,6 GiB
Comment 8 jeffrey.jeff 2020-02-15 14:34:51 UTC
I'm having the same issue. Copied files or text by ctr-c or context menu appear in clipboard widget but cannot be pasted. I need to copy content twice to be able to paste it.
I'm also running Arch Linux with KDE Plasma 5.18.
Comment 9 Nate Graham 2020-02-15 19:14:51 UTC
Are you pasting using a middle-click, the ctrl+v keyboard shortcut, or the menu item?
Comment 10 jkhsjdhjs 2020-02-16 00:01:37 UTC
(In reply to Nate Graham from comment #9)
> Are you pasting using a middle-click, the ctrl+v keyboard shortcut, or the
> menu item?

I'm usually pasting with ctrl+v, but I tested all three variants (middle-click by copying to PRIMARY of course) and all of them only work if I copy the data twice.
Comment 11 Nate Graham 2020-02-16 00:07:31 UTC
Strange. All three work fine for me with a single copy.
Comment 12 Michał Dybczak 2020-02-16 10:26:46 UTC
All works fine for me too. So when clicking on button "copy to clipboard in English" I can paste it right away, also clipboard shows it correctly, no need to repeat the action. I can't reproduce the bug.

Since more than one confirmed it and more than one can't reproduce it, there has to be some other factor influencing it.

To eliminate configs, create TEST user (clean user account with default settings), log into it and check if the issue happens there as well or not. If not, this is matter of local configs for given user on your machines.
Comment 13 Stefano Milani 2020-02-16 11:28:32 UTC
notice
bug appears only with a special configuration: If you're using Klipper (clipboard manager for KDE), this tool might prevent the clipboard from being cleared. You can disable this (i.e. allow clearing) by clicking the Klipper tray icon → 'Configure Klipper' → deactivate 'Prevent empty clipboard'. In this dialog, you furthermore might want to deactivate 'Save clipboard contents on exit' and reduce 'Clipboard history size' to 1, in order to prevent any sensitive data (e.g. passwords) from being saved. I had to do this because klipper saved passwords.
however I think this is a bug because it did not occur before version 5.18 (e.g. 5.17.5 ok 5.18 is bugged)
Comment 14 jkhsjdhjs 2020-02-16 20:34:43 UTC
@Stefano Milani: I set 'Clipboard history size' to 1 for the exact same reason. That's possibly the configuration option you - @Michał Dybczak and @Nate Graham - are missing to be able to reproduce this issue.
Also, as @Stefano Milani noted, 'Prevent empty clipboard' has to be disabled.
Comment 15 Michał Dybczak 2020-02-17 21:07:47 UTC
You are right. When I switched clipboard history to 1 and unchecked most of the settings (I'm unable to find 'Prevent empty clipboard', the translation probably is wrong) then the first click on 'Copy to clipboard in English' isn't working. Second one works, just like the bug described.

So now I can confirm, with certain settings' combination this bug does occur.
Comment 16 jkhsjdhjs 2020-02-18 00:18:20 UTC
(In reply to Michał Dybczak from comment #15)
> You are right. When I switched clipboard history to 1 and unchecked most of
> the settings (I'm unable to find 'Prevent empty clipboard', the translation
> probably is wrong) then the first click on 'Copy to clipboard in English'
> isn't working. Second one works, just like the bug described.
> 
> So now I can confirm, with certain settings' combination this bug does occur.

Thanks for confirming!
'Prevent empty clipboard' is the second option from the top under 'General Configuration' btw.
See this screenshot: https://screens.totally.rip/2020/02/5e4b2b07156e0.png
Comment 17 Michał Dybczak 2020-02-18 19:42:49 UTC
Thanks. After translation this options means for me "Never empty the clipboard".
Comment 18 Henrik Hudson 2020-02-19 18:55:58 UTC
I can confirm this issue as well. 

Arch Linux
Plasma: 5.18.0
Frameworks: 5.67.0
Qt: 5.14.1
Kernel: 5.4.20-lts

I have the following Klipper settings enabled / checked:
Ignore Images
Text Selection Only
Synchronize content of clipboard and selection

timeout for popups is 8 and history size is 1

All other options are not checked. ie: I want KeePass to be able to clear the buffer, so "prevent empty clipboard" is not checked.

I work mostly in Konsole and selecting text there once won't allow you to middle click. However, CTRL+v or Shift-Ins does work the first time. So, it seems to more tied to the middle click mouse action vs. the data not being in the buffer completely. However, if you double left-click to select a chunk of text then middle clicking works the first time. 

"Shift+Ins" should be the X selection buffer vs. the Ctrl+v copy/paste buffer.

So, possibly some action is being tied to "middle click" when you're doing a single click and drag to highlight and that is cleared the 2nd time? It really feels like the Klipper buffer is fine, but the mouse action isn't inserting the data correctly.
Comment 19 tagwerk19 2020-02-22 08:34:54 UTC
Seen in Neon Testing in a guest VM but it is *dependent* on the KVM host

This works:

Configuration and Setup:

    Neon-testing-20200204-1039.iso brought up to date 2020/02/22. Klipper version 5.18.1

    Running in a KVM guest. Host is Fedora 31, KDE Spin. Klipper version on host 5.17.5

    Clipboard configured (in host and guest) to "Ignore selection"; that is an explicit copy command is needed to put something in the clipboard, not just highlighting some text. Other settings left 'as is'.

    Klipper widget running in host and guest and pinned to desktops

    Testfile created in guest (with words "one" to "twelve" on separate lines) and opened with "vi"

Steps to test:

    Clear the clipboard history on the host and the guest (repeat if necessary until it says "Clipboard history is empty")

    Highlight and copy each line from the file in turn, watch to see if the word appears in Klipper's "Clipboard History" (in the guest). As said above, this works....

This does not work:

Copy the qcow2 image to a system running KDE Spin, Fedora 30, klipper version 5.15.5 and repeat the test:

Observed results:

    An unpredictable number of "copies" are needed before the word appears in the clipboard history. This is not deterministic. An empty entry can appear in the history as if there's an extra copy being done of a blank line.

    The clipboard history on the host can be out of step with the guest

It looks like communication between different versions of klipper on the host and the guest is affecting cut-and-paste (clipboard history) within the guest.
Comment 20 tagwerk19 2020-02-22 14:28:27 UTC
Created attachment 126293 [details]
Recording of tests within VM. Host: Fedora 30. Guest: Neon Testing, 5.18.1

Recording showing problems copying to clipboard, repeated attempts necessary, sometimes not working at all.

Clipboard top right from the host, bottom right from guest.
Comment 21 tagwerk19 2020-02-22 14:30:01 UTC
Created attachment 126294 [details]
Recording of tests within VM. Host: Fedora 31. Guest: Neon Testing, 5.18.1

Recording showing predictable, correct behaviour.
Comment 22 arne anka 2020-03-02 11:08:04 UTC
*** Bug 418178 has been marked as a duplicate of this bug. ***
Comment 23 Nate Graham 2022-01-21 05:48:02 UTC
Cannot reproduce in Plasma 5.4 (the beta). Is anyone else able to?
Comment 24 arne anka 2022-01-21 07:15:13 UTC
My bug (marked as duplicate in #22) is still present, though not as frequently as it used to be.
Comment 25 Stefano Milani 2022-01-30 14:31:03 UTC
with plasma 5.23.5 the bug is not reproducible
Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.3-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Celeron® CPU N3450 @ 1.10GHz
Memory: 5.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 500
Comment 26 jkhsjdhjs 2022-01-30 21:44:19 UTC
(In reply to Stefano Milani from comment #25)
> with plasma 5.23.5 the bug is not reproducible

I can still reproduce the bug with 5.23.5.
```
Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.2-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31,3 GiB of RAM
Graphics Processor: AMD Radeon RX 6700 XT
```

Klipper Configuration: https://screens.totally.rip/2022/01/61f7069937131.png
Comment 27 Harald Sitter 2022-02-21 08:03:58 UTC
Moving bug to plasmashell I rather think this has to do with the clipboard syncing between VM and host, nothing specific to kinfocenter specifically.
Comment 28 Jakub Kuczys 2022-07-06 06:21:54 UTC
Created attachment 150431 [details]
Recording of the bug on KDE Neon with Plasma 5.25.2

The attached recording was done directly on my PC without virtualization (KDE Neon is running from live USB here so that I don't have to install a fresh KDE Neon on the machine) as some comments here hinted at this being dependent on the KVM host but as seen here, it's reproducible without running KDE in VM.

This bug is still reproducible on KDE Plasma 5.25.2 though the "Prevent empty clipboard" option has been removed from the UI and only kept as a config file setting in this commit:
https://invent.kde.org/plasma/plasma-workspace/-/commit/99d0f172e4aa0e69ba55870493deac4963e0b239

The commit description says:
> Remove the "Prevent empty clipboard" option (but leave it as a hidden
> config file setting), it was difficult to explain and it is unclear if it
> ever had a use case.
But as I hope is clear from this bug, it does have a use case and that use case is preventing any sensitive data from being saved (e.g. passwords copied from password managers). What's worth noting is that currently, this option doesn't actually serve its purpose because it introduces this bug *and* clipboard clearing doesn't actually remove that entry from clipboard history when history size is set to 1.
Comment 29 Michał Dybczak 2022-07-06 18:54:51 UTC
On Manjaro with Plasma 5.25.2 I can't reproduce this bug. Are there any other reports from Kubuntu about it? If yes, this might be a packaging issue, if not... well... something is off on your installation.
Comment 30 Jakub Kuczys 2022-07-07 01:19:13 UTC
Created attachment 150454 [details]
Recording of the bug on openSUSE Tumbleweed with Plasma 5.25.2

The previous recording was on KDE Neon which is not Kubuntu and while it's based on Ubuntu, the KDE packages on it are made by KDE Neon maintainers, not Canonical or Kubuntu maintainers. But since it still is Ubuntu, I'm attaching a recording of the same bug on openSUSE Tumbleweed with Plasma 5.25.2. I wanted to record it on Manjaro but 5.25 hasn't reached stable yet and I didn't want to bother with getting unstable working.

One thing that is important when reproducing is that after changing Klipper's settings, you have to log out and log in again. Otherwise, the settings do not seem to apply.  This is true both for the hidden option that needs to be manually put in `klipperrc` as well as just changing the history size in the GUI which is quite easily observable since once you change the history size and clear the history, the history will keep growing to the previously set maximum count of entries (20 by default) rather than the newly set value (1 in the case of this bug).

In this recording, I tried to also show that after the first copy, the clipboard history gets updated even though the actual clipboard is empty until you copy the same value again. What's not shown on the recording is that this doesn't only apply to text but also to files which I ran into after I tried copying this recording to a USB drive :)
Comment 31 Michał Dybczak 2022-07-07 14:20:47 UTC
Switching to Manjaro unstable is super easy, just do:

sudo pacman-mirrors --api --set-branch unstable
sudo pacman -Syyu

To go back to stable, use the same commands as above, but use "stable".
Of course, do a backup before.
Comment 32 Jakub Kuczys 2022-07-07 21:54:24 UTC
Created attachment 150477 [details]
Recording of the bug within a VM running Manjaro with Plasma 5.25.2

Thanks for the commands; it's reproducible on Manjaro as well. One more thing I show on this video is how you only need a single copy *if* the clipboard history (and by extension also the clipboard though with more testing it seems that only clearing the clipboard without clearing history still makes it require a double copy) is empty.

Hypervisor Details:
- Hypervisor: KVM
- Architecture: x86_64
- Emulator: /usr/bin/qemu-system-x86_64
- Chipset: Q35
- Firmware: BIOS

I didn't try reproducing the bug in Manjaro without virtualization as I imagine that might be problematic to do from live USB with there being a default KDE version by default but, I feel like this has been pretty reliably reproducible with Plasma 5.25.2 and probably would be reproducible without virtualization as well.
Comment 33 Michał Dybczak 2022-07-09 11:04:46 UTC
I watched your video and I can't confirm this bug on my OS install. All works fine for the first time. If this was working as you showed on the video, this would be a MAJOR issue, because copy/paste cation is often used. Having to copy twice would be irritating as hell. There would be recent bug duplicates and other users reporting it. So far, that is not the case, and you are the only one experiencing it. The fact that you have this on multiple installs and distros shows that this has to be something specific to you and your settings.

Log in to a test, vanilla user and see if the bug is visible there as well. If not, this is a clearly a config issue, one that you are consistently doing and replicating all over your installs.
Comment 34 Michał Dybczak 2022-07-09 11:11:51 UTC
Wanted also to add, that I'm not using a virtual machine. My Manjaro install is on the bare metal. 
If I understand it correct, in all cases for you, you are using virtual machines? Then the other lead would be the virtualization or a specific hypervisor. I would be interested to see if this happens only in Plasma or in other desktops as well?

So far it seems a different issue than this one here. The first thing to establish would be if that is config issue. If not, do some tests on various virtual machines with various supervisors and desktops. Only then you will know where a bug should be reported, because it may not be related to Plasma at all.
Comment 35 Jakub Kuczys 2022-07-09 18:31:02 UTC
> If this was working as you showed on the video, this would be a MAJOR issue, because copy/paste cation is often used.

It wouldn't be because it is not a default configuration of Klipper. It requires you to set history size to 1 and have "Prevent empty clipboard" option not checked (on Plasma 5.25 this requires adding `NoEmptyClipboard=false` line to the config file setting as I mentioned in the earlier comment). I thought it's clear from the other people's comments on this issue and me including the used Klipper configuration on all of the recordings that this requires a specific configuration but I see now that I might not have made that entirely clear.

> Log in to a test, vanilla user and see if the bug is visible there as well. If not, this is a clearly a config issue, one that you are consistently doing and replicating all over your installs.

All of these are run on an unmodified user, other than changing these specific Klipper settings since that's part of the reproduction steps.

> If I understand it correct, in all cases for you, you are using virtual machines?

Only the Manjaro test uses a virtual machine. Everything else was being run on bare metal using a live USB image of the corresponding OS to ensure a clear environment. The only changes made are the changes to Klipper settings. I specifically did not use a virtual machine because I've seen that some of the comments here mentioned virtualization and I wanted to show that it's reproducible without it.

> I would be interested to see if this happens only in Plasma or in other desktops as well?

Since it requires a specific configuration of Klipper, it doesn't apply to non-KDE desktop environments since they don't use it. But since you asked, I did try doing the same thing on GNOME shipped with Ubuntu 22.04 (without any custom configuration as GNOME's clipboard manager that's responsible for keeping the clipboard contents after exiting the app is entirely internal with no user-facing interface and there are no features such as clipboard history in it, you would need a separate app for that) and this was not reproducible.
Comment 36 Nate Graham 2022-09-08 20:00:14 UTC
Is anyone able to post clear and consistent steps to reproduce so I can debug this?
Comment 37 Jakub Kuczys 2022-09-08 21:08:13 UTC
This should be reproducible on Plasma 5.25 using X11 with following steps.

1. Put this in `~/.config/klipperrc`:
```
[General]
MaxClipItems=1
NoEmptyClipboard=false
Version=5.25.2
```
2. Logout and relogin so that the new Klipper settings get loaded.
3. If your clipboard history is not empty, clear it.
4. Copy some text into your clipboard using Ctrl+C (only use the combination once).
5. Try pasting. This should work.
6. Copy some other text into your clipboard using Ctrl+C (only use the combination once).
7. Try pasting. This should fail.
8. Try copying the same text into your clipboard using Ctrl+C.
9. Try pasting. This should work.

On Plasma 5.24 (also using X11), you can replace step 1and 2 by setting the following configuration in Klipper's configuration window (on 5.25, the prevent empty clipboard option was removed from the UI but still intentionally kept as a newly named option `NoEmptyClipboard` which is what was used in the steps above instead of Klipper's UI). I access the configuration window by clicking on the clipboard icon in the taskbar and clicking the settings button in the top right corner of the clipboard manager that pops up.
The options that you need to set to reproduce this are:
- [ ] Prevent empty clipboard
- Clipboard history size: 1 entry
The rest of the settings are afaik irrelevant but here they are (these are the defaults afaik):
- [x] Save clipboard contents on exit
- [x] Ignore images
- [x] Ignore selection
- Timeout for action popups: 8 seconds

There's also a bunch of recordings made by me on Plasma 5.25 attached to this bug which you can also try watching to maybe see some additional way of reproducing that I didn't describe here in case you need it.

Let me know if you need anything else.
Comment 38 Nate Graham 2022-09-09 18:55:23 UTC
Thanks, I can reproduce the issue on X11 with those steps.

The key setting seems to be the combination of "MaxClipItems=1" and "NoEmptyClipboard=false" settings. If I remove either one, the issue stops happening with the same steps. Marking as a minor issue as this affects a rather unusual non-default set of settings, and there's a simple workaround.
Comment 39 Fushan Wen 2022-09-21 07:22:59 UTC
*** Bug 417729 has been marked as a duplicate of this bug. ***