Bug 464509

Summary: [Wayland] Copying text once from GTK app is registered by clipboard applet but subsequent copying of text from the same GTK app is not registered
Product: [Plasma] plasmashell Reporter: Bacteria <dev.bacteriostat>
Component: ClipboardAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: avelingker, bednarczyk.pawel, butirsky, m.orly97, nate, nerumo
Priority: VHI Keywords: regression
Version: 5.26.5   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.27
Sentry Crash Report:
Attachments: Video demonstrating the bug

Description Bacteria 2023-01-19 15:53:13 UTC
Created attachment 155427 [details]
Video demonstrating the bug

SUMMARY
Copying text once from GTK app is registered by clipboard applet but subsequent copying of text from the same GTK app is not registered. If I open another GTK app, for it too, copying gets registered first time but then stops getting registered after that. Clearing the clipboard resets the situation and you can copy once again.

To be clear that the normal copy paste operation works, it is just that the applet is not detecting it.

I am positive this bug comes from Frameworks 5.102, there were some changes made to address bug 454379, it might be a side-effect of that.

I have tested this with Firefox, Chromium, Signal, VSCode.  

STEPS TO REPRODUCE
1. Open a GTK app like Firefox, Chromium, Signal, VSCode.
2. Copy some text and check clipboard applet
3. Copied text shows in the clipboard
4. Copy text again from the same app and check clipboard applet

OBSERVED RESULT
The copied text does not show up in the clipboard applet

EXPECTED RESULT
It must show up in the clipboard applet

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 6.1.6-arch1-3 (64-bit)
Graphics Platform: Wayland
Comment 1 Nate Graham 2023-01-20 21:59:42 UTC
Can reproduce.
Comment 2 Bacteria 2023-01-21 05:54:13 UTC
This might address the issue but I don't use git version of plasma to test it out: https://invent.kde.org/plasma/kwin/-/merge_requests/3462
Comment 3 David Redondo 2023-01-24 10:31:16 UTC
Git commit d6b75907cca668d0c2b226d44dcab4ebe55e3b6b by David Redondo.
Committed on 24/01/2023 at 09:35.
Pushed by davidre into branch 'master'.

Data control: Resend selection when not following through with request

Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
FIXED-IN:5.27

M  +4    -0    src/wayland/seat_interface.cpp

https://invent.kde.org/plasma/kwin/commit/d6b75907cca668d0c2b226d44dcab4ebe55e3b6b
Comment 4 Vlad Zahorodnii 2023-01-24 10:34:40 UTC
Git commit fc1b6ccfa561a07a215cbc64ca6cc4e3d35e3fdf by Vlad Zahorodnii, on behalf of David Redondo.
Committed on 24/01/2023 at 10:34.
Pushed by vladz into branch 'cherry-pick-d6b75907'.

Data control: Resend selection when not following through with request

Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
FIXED-IN:5.27


(cherry picked from commit d6b75907cca668d0c2b226d44dcab4ebe55e3b6b)

M  +4    -0    src/wayland/seat_interface.cpp

https://invent.kde.org/plasma/kwin/commit/fc1b6ccfa561a07a215cbc64ca6cc4e3d35e3fdf
Comment 5 David Redondo 2023-01-24 10:58:29 UTC
Git commit a7e5d1da87b0efaedd18ef5b0e1228824c91e922 by David Redondo.
Committed on 24/01/2023 at 10:58.
Pushed by davidre into branch 'cherry-pick-d6b75907-2'.

Data control: Resend selection when not following through with request

Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
FIXED-IN:5.27


(cherry picked from commit d6b75907cca668d0c2b226d44dcab4ebe55e3b6b)

M  +4    -0    src/wayland/seat_interface.cpp

https://invent.kde.org/plasma/kwin/commit/a7e5d1da87b0efaedd18ef5b0e1228824c91e922
Comment 6 Fushan Wen 2023-01-25 12:55:54 UTC
*** Bug 464778 has been marked as a duplicate of this bug. ***