Bug 466041 - Data must be copied twice before being pasted on Wayland when history size is set to 1 entry
Summary: Data must be copied twice before being pasted on Wayland when history size is...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard (show other bugs)
Version: 5.27.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2023-02-19 00:03 UTC by Autumn
Modified: 2024-01-08 01:52 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.