Bug 466041

Summary: Data must be copied twice before being pasted on Wayland when history size is set to 1 entry
Product: [Plasma] plasmashell Reporter: Autumn <autumn>
Component: ClipboardAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: a.geno, apricus, buddha, enricobe, izzylaif, kde, kde, nate, phoenix_87_c, scooby95531, shtetldik, tustamido
Priority: NOR Keywords: wayland
Version: 5.27.0   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.27.3
Sentry Crash Report:

Description Autumn 2023-02-19 00:03:20 UTC
SUMMARY
When running a Plasma Wayland session with the clipboard configured to have a history size of only one entry, text and images can't be pasted after being copied unless the last thing copied was identical.

STEPS TO REPRODUCE
1. Start a Plasma Wayland session.
2. Configure Clipboard and set "History size" to 1 entry.
3. Copy text or an image once.
4. Try to paste it one or more times.
5. Copy the same text or image again.
6. Try to paste it one or more times.

OBSERVED RESULT
Nothing is pasted until the same text or image has been copied twice in a row. Clicking the clipboard applet shows whatever was copied, but pasting doesn't work.

EXPECTED RESULT
The text or image that was copied is pasted every time.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.12-arch1-1 (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION
This bug doesn't happen on X11, and it doesn't happen when the history size is two or more. It happens regardless of how the data is copied (Ctrl+C, context menu, "copy to clipboard" button, or wl-copy). I've only tested with text and images.
Comment 1 Enrico 2023-02-19 20:14:45 UTC
I can reproduce it on Debian Sid. The copied item can't be pasted until it's copied a second time.

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-5-amd64 (64-bit)
Graphics Platform: Wayland
Comment 2 Hexagon 2023-02-20 12:48:29 UTC
I can reproduce it on Arch as well. The problem also existed on Plasma 5.26 already.

Operating System: Arch Linux
KDE Plasma Version: 5.27.0-1
KDE Frameworks Version: 5.103.0-1
Qt Version: 5.15.8+kde+r181-1
Kernel Version: 6.1.12.arch1-1
Graphics Platform: Wayland
Comment 3 Nate Graham 2023-02-22 17:34:19 UTC
Can also reproduce 100%.
Comment 4 Shmerl 2023-02-24 18:59:07 UTC
Just hit the same bug. As a workaround I set the history to 2 entries for now.
Comment 5 Shmerl 2023-02-24 19:05:39 UTC
Btw, the problem didn't exist for me, until upgrade to newer frameworks happened (5.102 → 5.103). So it might be a regression in the new one.
Comment 6 tustamido 2023-02-27 15:47:35 UTC
For me the issue started with 5.27, didn't happen on 5.26. Still not fixed in 5.27.1.
Comment 7 David Redondo 2023-03-01 09:31:46 UTC
Confirmed, clipboard is unset but for some reason klipper updates primary selection but doesn't happen with history size 2
Comment 8 Bug Janitor Service 2023-03-01 15:43:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2684
Comment 9 David Redondo 2023-03-02 08:32:16 UTC
Git commit 85a05244ec2ac17dddbb9a4d59119b784e97ba49 by David Redondo.
Committed on 02/03/2023 at 08:15.
Pushed by davidre into branch 'master'.

klipper: Insert items before remove

If the history size is 1 removing before inserting can lead to a,
weird order of event:
- the clipboard is changed externally
- klipper is notified and insert is called
- the only item is removed since count == m_maxSize
- klipper notices the history is empty and clears the clipboard and selection
- adds the new item
- execution continues and klipper is notified selection is now empty
- to prevent empty  selection klipper sets it back to the new item
- same happens for the clipboard
This causes an issue on Wayland since klipper is notified about the
clipboard being empty while setting the selection and ignores the change, so
it is never set back. Instead do it in a more sensible way add the new clipboard
content first and then remove the excess item. This way klipper never unnecessarily
clears clipboard and selection.
FIXED-IN:5.27.3

M  +12   -11   klipper/historymodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/85a05244ec2ac17dddbb9a4d59119b784e97ba49
Comment 10 David Redondo 2023-03-02 11:27:52 UTC
Git commit 0cbe7da157847e8c74c058a805f407bbefb763c7 by David Redondo.
Committed on 02/03/2023 at 08:55.
Pushed by davidre into branch 'Plasma/5.27'.

klipper: Insert items before remove

If the history size is 1 removing before inserting can lead to a,
weird order of event:
- the clipboard is changed externally
- klipper is notified and insert is called
- the only item is removed since count == m_maxSize
- klipper notices the history is empty and clears the clipboard and selection
- adds the new item
- execution continues and klipper is notified selection is now empty
- to prevent empty  selection klipper sets it back to the new item
- same happens for the clipboard
This causes an issue on Wayland since klipper is notified about the
clipboard being empty while setting the selection and ignores the change, so
it is never set back. Instead do it in a more sensible way add the new clipboard
content first and then remove the excess item. This way klipper never unnecessarily
clears clipboard and selection.
FIXED-IN:5.27.3

(cherry picked from commit 85a05244ec2ac17dddbb9a4d59119b784e97ba49)

M  +15   -13   klipper/historymodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/0cbe7da157847e8c74c058a805f407bbefb763c7
Comment 11 Nate Graham 2023-03-05 22:42:34 UTC
*** Bug 433854 has been marked as a duplicate of this bug. ***
Comment 12 Marco 2023-12-19 09:40:34 UTC
I still have this issue on Plasma 5.27.10, frameworks 5.113.0
Comment 13 Marco 2023-12-19 09:43:59 UTC
Even by setting the history to 2 I still have the issue. What happens is that Klipper history gets updated correctly when I copy, but when I paste, the old string is pasted instead.
Comment 14 Matthew 2024-01-08 01:52:48 UTC
(In reply to Marco from comment #13)
> Even by setting the history to 2 I still have the issue. What happens is
> that Klipper history gets updated correctly when I copy, but when I paste,
> the old string is pasted instead.

I was having the same issue. Turned out to be an issue with KDE Connect. Having another PC paired was causing the issue.
Comment 15 izzylaif 2024-05-16 18:01:32 UTC
Not resolved. Still happening on Plasma 6.0.4/ F/w 6.1.0 with any size of history, I currently have 2 entries.
Comment 16 Nate Graham 2024-05-16 18:45:51 UTC
Then it's a different issue; this one was only about when your history size is set to 1. Please open a new bug report. Thanks!