xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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)

ticket870-first-session-copy-d-clipboard.txt.txt (4.7 KB) - added by alas 4 years ago.
debug while copying during session on first server
ticket870-second-session-paste-d-clipboard.txt.txt (10.0 KB) - added by alas 4 years ago.
debug from trying to paste in second session
ticket870-d-clipboard-copy1.txt (8.9 KB) - added by alas 4 years ago.
server logs of copy (ticket 870)
ticket870-d-clipboard-paste1.txt (14.1 KB) - added by alas 4 years ago.
server logs of paste attempt (ticket 870)

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by alas

debug while copying during session on first server

Changed 4 years ago by alas

debug from trying to paste in second session

comment:1 Changed 4 years ago by Antoine Martin

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 4 years ago by alas

Attaching server logs for server session copied from, and server session pasted into (unsuccessfully).

client: win32 0.15.0 r9470
server copied from: fedora 20 0.15.0 r9365
server pasted to: fedora 20 0.15.0 r9470

Changed 4 years ago by alas

server logs of copy (ticket 870)

Changed 4 years ago by alas

server logs of paste attempt (ticket 870)

comment:3 Changed 4 years ago by Antoine Martin

comment:4 Changed 4 years ago by Antoine Martin

Now that #918 is closed, this may already be fixed.

If that's not the case, r10114 adds the ability to avoid storing the clipboard contents on exit, which may help.
Use it like so (it defaults to "1" == enabled, as before) on Linux:

XPRA_CLIPBOARD_STORE_ON_EXIT=0 xpra attach ..

comment:5 Changed 4 years ago by alas

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 4 years ago by Antoine Martin

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 4 years ago by alas

Resolution: wontfix
Status: newclosed

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 4 years ago by Antoine Martin

Stumbled upon this today:

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)

Note: See TracTickets for help on using tickets.