diff options
| author | Jan-Marek Glogowski <glogow@fbihome.de> | 2020-03-25 18:33:29 +0100 |
|---|---|---|
| committer | Jan-Marek Glogowski <glogow@fbihome.de> | 2020-03-31 02:56:36 +0200 |
| commit | dbe45b7930dc027cf6d143dbb34390c469808e10 (patch) | |
| tree | 511eb670b0d4be3b41c3a9511d4c8cb9740af0dd /vcl/inc | |
| parent | c3a721eb602301be8ff87be6ade579209dd086fc (diff) | |
tdf#131533 Qt5 defer dropping clipboard ownership
This is maybe a Qt bug. Calling QClipboard::setMimeData from
Qt5Clipboard::setContents after a previous call to
QClipboard::clear results in a clipboard ownership failure.
In a terminal you'll see: "QXcbClipboard::setMimeData: Cannot set
X11 selection owner".
Calling Application::Reschedule() after the clear() doesn't help.
The result is a de-sync between the LO's clipboard state and the
real clipboard state, which will lead to a crash on LO shutdown.
I'm not sure this fix is correct. Maybe this could also be handled
by some X11 flush operation. But it's the only working solution I
could find: don't clear, if LO re-claims the ownership later.
I tried to reproduce the ownership error by modifying the Qt
fridgemagnets example, adding some QClipboard::clear and
QClipboard::setMimeData calls to the drop handling, but couldn't
reproduce. Maybe the dynamic Qt5MimeData object is also involved.
Change-Id: I32b6575a78a4b10a2e2b7b189303ab3a40dc69ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90990
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 313081c0703c66918e95640c74cd57312a1e8bba)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90963
Diffstat (limited to 'vcl/inc')
| -rw-r--r-- | vcl/inc/qt5/Qt5Clipboard.hxx | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/vcl/inc/qt5/Qt5Clipboard.hxx b/vcl/inc/qt5/Qt5Clipboard.hxx index 122184b44942..b99534f59039 100644 --- a/vcl/inc/qt5/Qt5Clipboard.hxx +++ b/vcl/inc/qt5/Qt5Clipboard.hxx @@ -41,6 +41,8 @@ class Qt5Clipboard final // has to be set, if LO changes the QClipboard itself, so it won't instantly lose // ownership by it's self-triggered QClipboard::changed handler bool m_bOwnClipboardChange; + // true, if LO really wants to give up clipboard ownership + bool m_bDoClear; // if not empty, this holds the setContents provided XTransferable or a Qt5ClipboardTransferable css::uno::Reference<css::datatransfer::XTransferable> m_aContents; @@ -55,6 +57,10 @@ class Qt5Clipboard final private Q_SLOTS: void handleChanged(QClipboard::Mode mode); + void handleClearClipboard(); + +signals: + void clearClipboard(); public: // factory function to construct only valid Qt5Clipboard objects by name |