Bug 442521 - buffer activated through Klipper's list can't be pasted to any panel's field
Summary: buffer activated through Klipper's list can't be pasted to any panel's field
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard (show other bugs)
Version: git-master
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: wayland
: 446835 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-09-16 13:27 UTC by Andrey
Modified: 2022-12-08 20:07 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.102
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey 2021-09-16 13:27:14 UTC
SUMMARY
Pasting from Klipper doesn't work for Panel's fields

STEPS TO REPRODUCE
1. select something from Klipper's list to paste
2. try to paste it by Ctrl+Shift+V e.g in Konsole
3. try to paste it in any Panel's fields (Kicker's "Search.." or e.g in some applet's settings)

OBSERVED RESULT
The pasting works OK in Konsole, but
nothing can be pasted in Panel, and I see following in the log:
QWaylandDataOffer: timeout reading from pipe
QWaylandDataOffer: error reading data for mimeType text/plain;charset=utf-8
QWaylandDataOffer: timeout reading from pipe
QWaylandDataOffer: error reading data for mimeType text/plain

EXPECTED RESULT
Pasting to Panel's fields should also work


SOFTWARE/OS VERSIONS
Operating System: Ubuntu 21.04
KDE Plasma Version: 5.22.80
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Graphics Platform: Wayland
Comment 1 David Edmundson 2021-09-16 14:03:56 UTC
This is a tough one, Qt (in Qt code) blocks when it reads clipboard data, so we block when trying to read data from ourselves.

Any use of threads to write the data won't help as it's too late, we're blocked before we can get notified to send anything.

Potentially we can update the regular clipboard from inside system clipboard, then Qt will think it owns the data and not try and fetch it remotely.
Comment 2 David Edmundson 2021-09-16 14:04:32 UTC
We also have this problem the other way round, if you copy something within plasma it won't get into the system clipboard.
Comment 3 Andrey 2021-09-16 15:40:28 UTC
(In reply to David Edmundson from comment #2)
> We also have this problem the other way round, if you copy something within
> plasma it won't get into the system clipboard.

BTW, that way we get empty items in Klipper
Comment 4 Bug Janitor Service 2021-09-29 13:11:39 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1086
Comment 5 David Edmundson 2021-12-11 21:55:33 UTC
*** Bug 446835 has been marked as a duplicate of this bug. ***
Comment 6 Bug Janitor Service 2022-05-17 11:39:08 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/55
Comment 7 Bug Janitor Service 2022-05-17 11:39:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1609
Comment 8 Bug Janitor Service 2022-12-07 15:00:30 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/80
Comment 9 David Redondo 2022-12-08 12:23:44 UTC
Git commit 3984732e007e71632a525d89227fdfe94fa037ad by David Redondo.
Committed on 08/12/2022 at 09:54.
Pushed by davidre into branch 'master'.

waylandclipboard: Update QClipboard when gaining focus

A process that owns the clipboard via KSystemClipboard (wlr-data-control)
and tries to read the clipboard via QClipboard  will deadlock itself and
eventually times out because the read is done blocking and the send event
is only received afterwards by WaylandClipboard.
When Qt knows it owns the keyboard it can get the data directly, so the
idea is to set QClipboard if possible. However this can be done only
when the Application has focus. Unfortunately inside Qt window system events
are delieverd asnycronously while QClipboard uses signal to indicate changes,
this makes QGuiApplication::focusWindowChanged not useable here because it
happens to late - after the QClipboard signal. For this reason we bind
to the wl_seat and track focus ourselves.
QClipboard takes ownership of QMimeData that is passed into it and so does
KSystemClipboard and ultimately DataControlSource which now uses unique_ptr
to signify this and make it clear that ownership is transferred when the
QClipboard is set.
Related: bug 454379

M  +5    -0    src/CMakeLists.txt
M  +106  -4    src/systemclipboard/waylandclipboard.cpp
M  +3    -0    src/systemclipboard/waylandclipboard_p.h

https://invent.kde.org/frameworks/kguiaddons/commit/3984732e007e71632a525d89227fdfe94fa037ad