#870 closed defect (wontfix)
When launched from launcher, clipboard contents are deleted from client upon disconnect
Reported by: | alas | Owned by: | alas |
---|---|---|---|
Priority: | minor | Milestone: | 0.16 |
Component: | client | Version: | 0.15.x |
Keywords: | Cc: |
Description
Testing for #864, connecting between two different servers with a win32 0.15.0 r9470 client (fedora 20 0.15.0 r9470 and r9374 servers), I found that text copied to clipboard while connected to one server were cleared upon disconnection.
The clipboard behaved as if it had no contents after disconnection. I couldn't paste anything locally after disconnection, and I couldn't paste anything into a subsequently connected session.
(The testing involved encryption and a password, which seems to have ruined my attempt to capture xpra info - let me know if it is useful and I can grab tomorrow.)
Attaching:
- A server side log clip with
-d clipboard
from the connection to the first session (0.15.0 r9374 server) - connecting, copying some text, then disconnecting. - A server side log clip with
-d clipboard
from the connection to the second session (0.15.0 r9470, built--with-memoryviews
) - connecting, (failing to) paste some text, then disconnecting.
Attachments (4)
Change History (13)
Changed 7 years ago by
Attachment: | ticket870-first-session-copy-d-clipboard.txt.txt added |
---|
Changed 7 years ago by
Attachment: | ticket870-second-session-paste-d-clipboard.txt.txt added |
---|
debug from trying to paste in second session
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to alas |
---|
Looks like the problem may be on the server side:
process clipboard packet type=clipboard-contents-none
Please include the server log excerpt for each case.
comment:2 Changed 7 years ago by
Changed 7 years ago by
Attachment: | ticket870-d-clipboard-copy1.txt added |
---|
server logs of copy (ticket 870)
Changed 7 years ago by
Attachment: | ticket870-d-clipboard-paste1.txt added |
---|
server logs of paste attempt (ticket 870)
comment:4 Changed 7 years ago by
comment:5 Changed 7 years ago by
Just tested again with 0.16.0 r10655 win32 client against 0.16.0 r10624 fedora 21 server... and the clipboard contents are still being wiped when disconnecting (after launching with the gui/icon or with the cmd terminal window).
Setting the XPRA_CLIPBOARD_STORE_ON_EXIT=
1 or 0 doesn't seem to make any difference. Disconnecting with the tray icon or a control C also doesn't seem to make any difference. (I suspect setting the variable on the server wouldn't help with pasting anything after a disconnect... so I didn't test that.)
comment:6 Changed 7 years ago by
Forgot to ask: is this a regression?
One important thing I need clarification on: does this make the clipboard unusable or does it just prevent pasting text after disconnecting? (the former would be a bug, the latter not)
It could just be that GTK is unhelpfully clearing the clipboard as it releases it when we exit.
In which case, I would close this ticket as wontfix and try to do better in #812.
comment:7 Changed 7 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Hmm, a regression? I'm not really sure... it's just something I noticed one day.
For clarification - it does NOT make the clipboard unusable at all, it just wipes the contents after a disconnection.
That said, I guess I'll close this for you as wontfix. (It's hardly a big deal, was just a minor annoyance while trying to capture some info for some test.)
comment:8 Changed 7 years ago by
Stumbled upon this today:
- This is not a GTK or PyGTK issue, but a consequence of how X11 copying and pasting works
- Coding Copy and Paste Functionality
- gtk.gdk.Display.supports_clipboard_persistence
And we already expose this with GTK_info.exe
on win32, where you can see that clipboard_persistence
is NOT supported.
(even if it was supported on win32, it looks like we may need to also call set-can-store before calling store)
comment:9 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/870
debug while copying during session on first server