[copy & paste]: only possible while original window is open

[star-buck]

reproduce:

1. add new text file with some random text in dolphin
2. select & copy random text
3. close kate
4. open firefox
5. try to "Paste" random text into google searchfield is not possible
6. open text file with kate again
7. select and copy random text
8. firefox: able to paste text while leaving kate open, as soon as you close kate the "Paste" option becomes unavailable again

[eikehein]

In X11, the app you copy from is responsible for handing over the data when you paste. So you can't paste when the app was closed first. This is the original reason for creating Klipper; it monitors for copies and takes over as the app responsible for handing over the data.

-> Klipper isn't running.

[mgraesslin]

Klipper isn't running.

This might be wrong. The problem is reproducable with Klipper running. But the data is made available to Klipper. I do not know what is causing the regression. If anyone knows how QClipboard works, I would be very glad if he could look at it.

[star-buck]

just to confirm: I checked of course if klipper was running...

[mgraesslin]

I'm assuming this is a regression in Qt. Klipper has code to reset the clipboard content, but that code path isn't entered when a window holding the current clipboard content closes. Will have to investigate what the code did in Qt4.

[eikehein]

(Makes me nostalgic, I was on IRC at least twice when Lubos cursed like a sailor over fixing complex Klipper edge cases ...)

[mgraesslin]

Patch for Qt, which makes it working again:

diff --git a/src/plugins/platforms/xcb/qxcbclipboard.cpp b/src/plugins/platforms/xcb/qxcbclipboard.cpp
index 8b3893e..f56a29d 100644
--- a/src/plugins/platforms/xcb/qxcbclipboard.cpp
+++ b/src/plugins/platforms/xcb/qxcbclipboard.cpp
@@ -742,7 +742,8 @@ void QXcbClipboard::handleXFixesSelectionRequest(xcb_xfixes_selection_notify_eve
             m_xClipboard[mode]->reset();
         }
         emitChanged(mode);
-    }
+    } else if (event->subtype == XCB_XFIXES_SELECTION_EVENT_SELECTION_CLIENT_CLOSE)
+        emitChanged(mode);
 }

[mgraesslin]

Related KDE Bug: https://bugs.kde.org/show_bug.cgi?id=329174 Qt Code Review: https://codereview.qt-project.org/101845

This will take some time - it can earliest go into Qt 5.4.1 and then we need to wait till it is available in distributions.

[mgraesslin]

That went faster than expected: it's already merged into 5.4 branch

[star-buck]

apachelogger: please see if we can patch this into kci

[mgraesslin]

package: libqt5gui5 fixed: Dec, 10th target ISO: unknown

[hsitter]

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-15-ci-fixes/+sourcepub/4691840/+listing-archive-extra

[star-buck]

rebooted, but seems its still not working: https://www.dropbox.com/s/5yrbd0e45ay9p05/copy-paste.mkv?dl=0

[mgraesslin]

could you please test with not Firefox - I just want to be sure it's not a side-effect of something else.

[star-buck]

dolphin - rename: copy the filename, paste in textfile works, when closing dolphin pasting no longer works. so what usecase example does work for you, so i can try that?

[mgraesslin]

Just tried the steps from Dolphin on my system with the patch. It works as expected.

I'm now a little bit puzzled why it doesn't work with the patched package.

[star-buck]

im also puzzled why it doesnt? maybe it does need some other packages required like a certain version of frameworks?

[mgraesslin]

I wouldn't be aware of any frameworks dependency - and in any case it should be in the repository already.

What might be possible is that my change in Qt builds up on another required change I wasn't aware of or that more Qt packages are required to update (I'm not a packaging expert after all).

[notmart]

Seems that firefox never sends XCB_XFIXES_SELECTION_EVENT_SELECTION_CLIENT_CLOSE when closes

it just sends a bunch of XCB_XFIXES_SELECTION_EVENT_SET_SELECTION_OWNER if i change qt xcb in the following way, it seems to work, but it looks very wrong (as that emit it deliberately avoided in the previous code)

diff --git a/src/plugins/platforms/xcb/qxcbclipboard.cpp b/src/plugins/platforms/xcb/qxcbclipboard.cpp
index f56a29d..2d678e0 100644
--- a/src/plugins/platforms/xcb/qxcbclipboard.cpp
+++ b/src/plugins/platforms/xcb/qxcbclipboard.cpp
@@ -742,7 +742,7 @@ void QXcbClipboard::handleXFixesSelectionRequest(xcb_xfixes_selection_notify_eve
             m_xClipboard[mode]->reset();
         }
         emitChanged(mode);
-    } else if (event->subtype == XCB_XFIXES_SELECTION_EVENT_SELECTION_CLIENT_CLOSE)
+    } else
         emitChanged(mode);
 }

[mgraesslin]

I cannot reproduce with Qt5 applications on ISO. E.g. open systemsettings, enter in search, copy the search field content, close window, paste.

But I can reproduce with Qt4 applications on iso and also on my primary system. This explains why I was not able to reproduce with the dolphin example: I had a Qt 5 app here.

[star-buck]

oddly enough, copy&paste seems to work for all scenarios with manjaro ISO (tested in LIVE-mode from usb): http://sourceforge.net/projects/manjarotest/files/0.9.0/kf5-plasma-dev/manjaro-kde-0.9.0-pre2-x86_64.iso/download Can someone confirm its working and spot the packages they use for why?

[mgraesslin]

code review for latest findings: https://codereview.qt-project.org/105556

[mgraesslin]

Can someone confirm its working and spot the packages they use for why?

they use a Dolphin based on Qt 5, so it's not surprising that it works.

[star-buck]

But its apparently also working from firefox to kate with ff closed?

[mgraesslin]

But its apparently also working from firefox to kate with ff closed?

Isn't netrunner using some pre-load hacks to start Firefox during session startup? This might influence the way it tears down. From the investigation there are two different ways to notify that the clipboard is no longer valid. It might be that Firefox uses different pathes. Anyway the patch I created for Qt handles both now. And I do hope there is no third way ;-)

[star-buck]

Netrunner 15 doesnt use any preload. Manjaro seems to work with all cases gtk2/3, etc., so i wonder what makes it work and fail in kci/netrunner.

[mgraesslin]

only guessing: maybe different GTK versions (Netrunner has 3.12, Manjaro according to distrowatch 3.14), maybe patches to GTK. Maybe different X11 versions with different behavior. The matrix is huge what could influence it.

[hsitter]

yep https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-15-ci-fixes/+sourcepub/4759133/+listing-archive-extra

[notmart]

so, here works with firefox with the following patch in qtbase: http://paste.opensuse.org/54171834

i'm not sure is a correct thing to upstream, since may have side effects. but can it be tried to be put in the package?

[hsitter]

that is conflicting with https://codereview.qt-project.org/#/c/105556/ are you sure about this?

[notmart]

yes, it would replace that one (that one is still technically more correct but yeah... not pretty ;)

[hsitter]

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-15-ci-fixes/+sourcepub/4766467/+listing-archive-extra

[star-buck]

fixes seem to work. I eventually noticed this though (needs to be confirmed): If you UNTICK the entry for systray under Extra Items, clipboard seems to be bypassed, since pasting then works fine again only until you close the window where you copy from.

[mgraesslin]

If you UNTICK the entry for systray under Extra Items, clipboard seems to be bypassed, since pasting then works fine again only until you close the window where you copy from.

yes that's to be expected as that item is providing the functionality to restore clipboard content when a window closes. That's the primary reason why Klipper got created in the first place.

[star-buck]

and closed!