tdf#140404 Qt ignore "unchanged" clipboard events

LO gets a Qt signal on all clipboard changes. For X11 you get one
signal when you set the clipboard. Anything else normally signals
lost of clipboard ownership.

But on Wayland LO somehow gets a second notification without any
actual change. AFAIK it's not triggered by any LO actions and
isOwner still indicates, that LO has the ownership. This breaks
the single notification assumption, the code was relying on.

Initially I found it quite tricky to find a rule to identify the
ignorable change signals.

Change-Id: I744cdd3c4254533b01d909309ecc3967d789361e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113617
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins

1 files changed, 9 insertions, 0 deletions

diff --git a/vcl/qt5/Qt5Clipboard.cxx b/vcl/qt5/Qt5Clipboard.cxx
index 8720cfe44310..41881f0be4b6 100644
--- a/vcl/qt5/Qt5Clipboard.cxx
+++ b/vcl/qt5/Qt5Clipboard.cxx
@@ -150,6 +150,15 @@ void Qt5Clipboard::handleChanged(QClipboard::Mode aMode)
 
     osl::ClearableMutexGuard aGuard(m_aMutex);
 
+    // QtWayland will send a second change notification (seemingly without any
+    // trigger). And any C'n'P operation in the Qt file picker emits a signal,
+    // with LO still holding the clipboard ownership, but internally having lost
+    // it. So ignore any signal, which still delivers the internal Qt5MimeData
+    // as the clipboard content and is no "advertised" change.
+    if (!m_bOwnClipboardChange && isOwner(aMode)
+        && dynamic_cast<const Qt5MimeData*>(QApplication::clipboard()->mimeData(aMode)))
+        return;
+
     css::uno::Reference<css::datatransfer::clipboard::XClipboardOwner> xOldOwner(m_aOwner);
     css::uno::Reference<css::datatransfer::XTransferable> xOldContents(m_aContents);
     // ownership change from LO POV is handled in setContents