Bug 417590

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.

Does the regular copy to clipboard button work reliably?

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.

(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).

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.

Just found a workaround: In the klipper configuration enable "Prevent empty clipboard".

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

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.

Are you pasting using a middle-click, the ctrl+v keyboard shortcut, or the menu item?

(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.

Strange. All three work fine for me with a single copy.

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.

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)

@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.

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.

(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

Thanks. After translation this options means for me "Never empty the clipboard".

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.

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.

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.

Created attachment 126294 [details]
Recording of tests within VM. Host: Fedora 31. Guest: Neon Testing, 5.18.1

Recording showing predictable, correct behaviour.

*** Bug 418178 has been marked as a duplicate of this bug. ***

Cannot reproduce in Plasma 5.4 (the beta). Is anyone else able to?

My bug (marked as duplicate in #22) is still present, though not as frequently as it used to be.

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

(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

Moving bug to plasmashell I rather think this has to do with the clipboard syncing between VM and host, nothing specific to kinfocenter specifically.

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.

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.

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 :)

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.

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.

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.

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.

> 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.

Is anyone able to post clear and consistent steps to reproduce so I can debug this?

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.

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.

*** Bug 417729 has been marked as a duplicate of this bug. ***

I have the same with any applications

Linux/KDE Plasma: 
Fedora release 36 (Thirty Six) 
KDE Plasma Version: 
plasmashell 5.27.1
KDE Frameworks Version: 
Version 5.103.0
Qt Version: 
Version 5.15.8 (built against 5.15.8)