tray menu clipboard choice irreversible

[beelzebug]

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

[Antoine Martin]

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

[beelzebug]

(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;-).

[Antoine Martin]

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)

[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.

[Antoine Martin]

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

Lots of fixes now in trunk:

• debugging: r12492, r12493
• handle disabled clipboard without timeouts: r12494, r12495
• fix re-enable clipboard: r12496

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?

[Antoine Martin]

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

[migration script]

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