xpra icon
Bug tracker and wiki

Opened 8 weeks ago

Closed 8 weeks ago

Last modified 8 weeks ago

#2689 closed defect (wontfix)

Clipboard: Can't copy from gitk primary on Linux server to Windows client

Reported by: pm54389 Owned by: Antoine Martin
Priority: major Milestone: 4.0
Component: clipboard Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

Hi,

Found another clipboard issue...

Client: Windows 7, v4.0-r25796
Server: RHEL 7.7, v3.0.5-r24939

Client xpra.conf contains remote-clipboard=PRIMARY (see #2638 for full config)

Steps to reproduce:

  • cd to somewhere in a git workspace
  • optional: run xpra clipboard-test &
  • gitk
  • in the pane where Author, Committer, etc are shown: highlight some text in the commit description by clicking and dragging (not too fast; the area selected needs to start small and grow). Example: "abcdefgh"
  • optional: use xpra clipboard-test to verify that PRIMARY now contains "abcdefgh"
  • paste into Notepad. It should paste "abcdefgh", but actually only pastes the first few letter(s), e.g. "ab"
  • also, if you now highlight different text in the same pane in gitk (example: "xyz"), xpra clipboard-test shows that PRIMARY now contains "xyz", but pasting into Notepad still pastes "ab"

gitk version is the version included with git 2.21.0 (gitk itself doesn't seem to have a --version flag or similar)
Tk version: 8.5.13

Let me know if you need more info...

Attachments (2)

server.txt (4.8 KB) - added by pm54389 8 weeks ago.
client.txt (1.9 KB) - added by pm54389 8 weeks ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 8 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to pm54389

Can you attach the -d clipboard log?

Changed 8 weeks ago by pm54389

Attachment: server.txt added

Changed 8 weeks ago by pm54389

Attachment: client.txt added

comment:2 Changed 8 weeks ago by pm54389

Owner: changed from pm54389 to Antoine Martin

Attached. The logs show:

  • launch gitk (it seems to copy the sha1 of the latest commit to CLIPBOARD on startup)
  • select text "resolve" (doesn't seem to log anything)
  • click "Get String" for PRIMARY in xpra clipboard-test: shows "resolve" (doesn't seem to log anything)
    • btw, I noticed in a separate run that "Get String" for CLIPBOARD at this point shows "r"
  • paste in Notepad: pastes "r"

comment:3 Changed 8 weeks ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Looks like the server log doesn't have -d clipboard? (I only see the client clipboard debug output in there)
We should be sending a new token with the clipboard data every time the selection changes on the server, that's because mswindows clients are 'greedy' and won't be asking us for the clipboard contents when they're needed, so we have to ensure the contents are always up to date.

comment:4 Changed 8 weeks ago by Antoine Martin

Resolution: wontfix
Status: assignedclosed

I don't think there's much we can do about this.

Other well behaved applications will use XFixesSelectionNotify, ie with xterm:

do_xpra_xfixes_selection_notify_event(<X11:XFSelectionNotify
    {'send_event': '0', 'serial': '0x114fd', 'delivered_to': '0x400008', 
     'window': '0x400008', 'subtype': '0', 'owner': '0x60002d',
     'selection': 'PRIMARY', 'timestamp': '238200596',
     'selection_timestamp': '238200595'
    }>)

That's how you're supposed to get clipboard change notifications...
See Use XFixesSelectSelectionInput() from Xfixes extension and wait for XFixesSelectionNotify event.

As per the spec: The XFIXES Extension:
Selection Tracking: Applications wishing to monitor the contents of current selections must
poll for selection changes. XFIXES improves this by providing an event
delivered whenever the selection ownership changes.

This notification was part of xfixes version 2, released sometime in the mid-2000s...

Without it, we would have to poll the clipboard continuously. That's horrible and we already blacklist any application that does that (ie: clipit), so not an option.

comment:5 Changed 8 weeks ago by pm54389

Ok, that makes sense, thanks. (Sorry about the logs - must have missed the -d clipboard on the server.)

I just found a page about the Cygwin clipboard that mentions this is a problem with Tk applications: https://x.cygwin.com/docs/ug/using-clipboard-integration.html

Note: See TracTickets for help on using tickets.