Xpra: Ticket #1167: tray menu clipboard choice irreversible

This is xpra 0.16 on GNU/Linux, with only local instances of xpra so far, using --mmap-group to share session between users.

The tray icon offers some clipboard choices: disabled, clipboard, primary, secondary. When having started the session with --clipboard=yes, none of these is selected and I can copy and paste with Ctrl+c/v and the middle mouse button as usual between host and xpra session.

The first issue is with the GUI: Once I had chosen primary, I can switch to clipboard, but there is nothing to select to get all of them again.

The second issue: Once I have chosen disabled, there is no clipboard action at all anymore, even after selecting some other entry from the menu. I see this in the terminal:

2016-04-15 16:48:41,343 Attached to :201 (press Control-C to detach)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed
    self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper)
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper
    return helperClass(clipboard_send, clipboard_progress, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__
    self.local_clipboard = getselection("local")
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection
    assert selections, "no %s clipboards!" % name
AssertionError: no local clipboards!
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed
    self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper)
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper
    return helperClass(clipboard_send, clipboard_progress, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__
    self.local_clipboard = getselection("local")
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection
    assert selections, "no %s clipboards!" % name
AssertionError: no local clipboards!
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 512, in remote_clipboard_changed
    self.client.setup_clipboard_helper(TranslatedClipboardProtocolHelper)
  File "/usr/lib/python2.7/site-packages/xpra/client/gtk2/client.py", line 286, in setup_clipboard_helper
    return helperClass(clipboard_send, clipboard_progress, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 36, in __init__
    self.local_clipboard = getselection("local")
  File "/usr/lib/python2.7/site-packages/xpra/clipboard/translated_clipboard.py", line 31, in getselection
    assert selections, "no %s clipboards!" % name
AssertionError: no local clipboards!

My python is version 2.7.11 and there are fairly recent versions of other system stuff. I hope this is not too hard to fix. With this switch of clipboard on the fly, xpra is really useful as a application separation method with the optional exchange of information only after I allowed it. Ideally, I would start it with --clipboard=no and enable it once I want to copy something over. Normally, I do not want the possibility of xpra-contained applications sniffing other things in the primary selection (p.ex. passwords).



Sat, 16 Apr 2016 02:18:25 GMT - Antoine Martin: status changed

Please specify your client OS. I assume this is MS Windows?


Sat, 16 Apr 2016 22:56:28 GMT - beelzebug: component changed

(Hm, so Trac does not add comments based on mails … so I needed some time to grab that password remotely.)

So to the question of client OS: No, not MS Windows. I also see now that there is an Android component selected. That is also wrong, I guess it's a client issue. This is on a GNU/Linux x86-64 machine, working with xpra locally only, client and server (however you define that with X11;-).


Sun, 17 Apr 2016 07:07:45 GMT - Antoine Martin: owner, status changed

Ah, Linux should not be using this menu at all - it doesn't make any sense there: the menu is only useful for platforms that have a single clipboard to sync with (win32 and osx), as it allows us to select which one.

r12402 + r12416 fixes that - a bit ugly. (r12408 for v0.16.x) Found some other things that needed fixing or improving along the way: r12403, r12404, r12405, r12406

Hopefully, we can clean this up some more in the next release as part of #276.

@beelzebug: does this work for you? (in trunk now)


Mon, 18 Apr 2016 13:21:30 GMT - beelzebug:

Yes, this only shows a single toggle for clipboard now (r12408 on top of 0.16.3).

Now … if this would work to enable the clipboard again, too, I would be happy. Is that supposed to work? So far, I can only one-time disable the clipboard wholesale. My security considerations would be fully fulfilled if I had that on/off switch, with the added twist that switching it back on only synchronises new selections/clipboard copies (Ctrl+C), not existing ones.

How far off is that? But, well, it might be another ticket, as the confusing tray menu is gone, although it still confuses that I cannot reactivate the clipboard.


Mon, 25 Apr 2016 11:37:08 GMT - beelzebug: owner changed


Sat, 30 Apr 2016 08:08:21 GMT - Antoine Martin: owner changed

It kinda worked when you re-enable it, but not in all cases..

Lots of fixes now in trunk:

The non-debug changesets should be backported, but this needs testing first to ensure I haven't broken anything else.. @beelzebug: does this work for you?


Tue, 09 Aug 2016 15:04:56 GMT - Antoine Martin: status changed; resolution set

Not heard back for 3 months, assuming this is fixed. Backport was in r12506.


Sat, 23 Jan 2021 05:16:48 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1167