Bug 484409 - Clipboard is sent to phone when locking / unlocking screen
Summary: Clipboard is sent to phone when locking / unlocking screen
Status: REPORTED
Alias: None
Product: kdeconnect
Classification: Applications
Component: common (show other bugs)
Version: 24.02.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-24 19:53 UTC by arjanmarku02
Modified: 2024-04-05 21:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description arjanmarku02 2024-03-24 19:53:51 UTC
SUMMARY
Locking / Unlocking in EndeavourOS (KDE Plasma 6) will produce some annoying "Copied to clipboard" toasts, it doesn't have any real effect in the clipboard itself.
The only thing that locking does is that it clears the current clipboard selection in GBoard which is again annoying as the clipboard content is still there.

STEPS TO REPRODUCE
1. Ensure KDEConnect-KDE and KDEConnect-Android are properly connected and you have at least an item in your clipboard.
2. Wait for plasma to suspend or lock the screen (Meta + L).
3. Wait for some time and unlock it.

OBSERVED RESULT
Both 2 and 3 should cause a "Copied to clipboard" toast in your android.

EXPECTED RESULT
No toast is shown since nothing changed in the clipboard content worth of transmitting.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: EndeavourOS / KDE Plasma 6.0.2
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
The reason why those packets are sent in the first place is not very clear to me. 
I managed to narrow it down to the DataControlDevice#zwlr_data_control_device_v1_selection in KGuiAddons/src/systemclipboard/waylandclipboard.cpp which emits a receivedSelectionChanged() signal which has empty text.
I found some threads that mention that locking should clear the clipboard, not sure if that has anything to do with this.
Maybe these signals that originate from lock / unlocking have a meaning in other places but I think that KDEConnect should ignore it.