fix/improve MS Windows clipboard handling

[totaam]

Issue migrated from trac ticket # 272

component: platforms | priority: major | resolution: fixed | keywords: clipboard win32

2013-02-28 09:59:16: antoine created the issue

---

Split from #11. Please see Clipboard first.

• it should be possible to keep track of the last "clipboard" ("primary", "secondary" or "clipboard") that the server claims to own and copy from that one when the client requests the clipboard contents (or when it requests the list of formats). Beware: there may be races here if we use a naive implementation... we could end up requesting data in a format which is not supported by the last clipboard token.
  This should take of copy+paste from server to client.

• client to server: we can simply claim that we own all three clipboards at once, when the server requests the contents we give it the only contents we have. (this direction is easier)

There may well be some cases where this causes problems, or where the user chooses to sync with a single clipboard, so we probably want to add a new UI and command line option (win32 clients only):

--clipboard-sync=primary|secondary|clipboard|all

"all" would be the new "auto" mode.

[totaam]

2013-03-04 12:24:22: antoine commented

---

mostly done in r2855, not done the UI since the default is probably better than what we had before.

Despite knowing very well that I needed to turn off VirtualBox's own clipboard synchronization, I forgot about it and thought the whole thing was broken... beware when testing!

[totaam]

2013-03-08 04:09:44: afarr commented

---

With a Fedora 18 server with xpra 0.9.0 and a windows client with 0.8.7 I have found the following behaviors.

1. Copying on the windows client loads the content into all three of the server clipboards (primary, secondary & clipboard). Pasting works consistently in this case.

2. Copying in the xpra window loads the data into the primary clipboard and the clipboard clipboard, but not the secondary clipboard.

a. The first such copy will produce correct results when pasting to the windows client. Copying a second (or subsequent) set of data will update the data in both the primary and clipboard clipboards, but attempts to paste into the windows client will result in pasting the first set of data repeatedly. (The pasting will behave correctly within the xpra window(s), meanwhile.)

b. Highlighting and deleting data in the xpra window will copy that data to the primary clipboard (leading me to believe that it is used as an 'undo' storage location), while it will clear the secondary clipboard (if not already clear) and it will also (often, but somewhat erratically) clear the clipboard clipboard. --> At this point, however, pasting to the windows client will produce unpredictable results, often the pasting of some portion of the "deleted" text stored in the primary clipboard.

c. Once the clipboard clipboard has thusly been cleared, whatever is next copied will be "transmitted" to the windows client clipboard and can be pasted. (And will likewise continue to be repasted and repasted again, until another such deletion resets the clipboard, or something is copied anew from the windows client, filling all three clipboards.)

d. Sometimes, however, the clipboard clipboard won't be cleared. In that case, the windows clipboard will continue to "resist" updating with any new copied data.

3. I also noticed that calls with xclip to output the contents of the secondary clipboard always produced a debugging message from the client indicating that it was being asked for clipboard data when it wasn't expecting to be so queried. I take that to mean that the secondary clipboard is intended to be used for data from outside of the local environment.

4. Windows also seems to have an "undo" clipboard somewhere, which occasionally seems to confuse matters if clipboard contents don't "initialize" when an xpra session starts, in which case- despite having recently copied something from the windows client environment (before beginning the xpra session), an attempt to paste into the xpra will paste no data... and if one then tries to paste back into the windows environment something random will be pasted (which may or may not be drawn from the windows "undo" clipboard in much the same way that pasting sometimes results in pulling "deleted" data from the primary clipboard).

In general:

1. If all three clipboards have data then most likely the last copy was from the client.

2. If the primary and clipboard clipboards have data, then the last copy was from within the xpra environment.

3. If only the primary clipboard has data, then most likely there was a recent deletion.

4. If the data in the primary clipboard and the clipboard clipboard are different, the clipboard will generally have the latest "copy data" while the primary will have the "delete data".

Unfortunately, the behavior is just buggy enough to resist a clear understanding or predictability.

[totaam]

2013-03-08 04:42:24: antoine commented

---

Do you have any log samples for each one?

1. Copying on the windows client loads the content into all three of the server clipboards (primary, secondary & clipboard). Pasting works consistently in this case.
   OK

2. Copying in the xpra window loads the data into the primary clipboard and the clipboard clipboard, but not the secondary clipboard.
   Not exactly: some applications load into 'primary', some in 'clipboard' and some (very rare) in 'secondary'. (and some in more than one at the same time)
   This is done by the application only and is totally beyond our control.
   Generally speaking, simply selecting/highlighting some text places it in 'primary', without any need to 'copy' it (via Control-C or via a menu).
   This is also why we really do not want to send clipboard data to the other end every time the clipboard contents change, but only when clipboard contents are requested by it. (imagine dragging the mouse over some large amount of text and the bandwidth hog this would generate)

a. The first such copy will produce correct results when pasting to the windows client. Copying a second (or subsequent) set of data will update the data in both the primary and clipboard clipboards, but attempts to paste into the windows client will result in pasting the first set of data repeatedly. (The pasting will behave correctly within the xpra window(s), meanwhile.)
Confirmed. That's odd, sounds like something is owning the clipboard client side.
I may knock up a test application we can run on win32 to show clipboard events.
All the problems below may well be due to this one.

b. Highlighting and deleting data in the xpra window will copy that data to the primary clipboard (leading me to believe that it is used as an 'undo' storage location), while it will clear the secondary clipboard (if not already clear) and it will also (often, but somewhat erratically) clear the clipboard clipboard. --> At this point, however, pasting to the windows client will produce unpredictable results, often the pasting of some portion of the "deleted" text stored in the primary clipboard.
I don't understand the 'undo' comments. And what do you mean by 'deleting data'?

c. Once the clipboard clipboard has thusly been cleared, whatever is next copied will be "transmitted" to the windows client clipboard and can be pasted. (And will likewise continue to be repasted and repasted again, until another such deletion resets the clipboard, or something is copied anew from the windows client, filling all three clipboards.)
Due to (b), I'm not sure I understand.

d. Sometimes, however, the clipboard clipboard won't be cleared. In that case, the windows clipboard will continue to "resist" updating with any new copied data.
Same. Why should it be cleared? Its contents are down to the application.

3. I also noticed that calls with xclip to output the contents of the secondary clipboard always produced a debugging message from the client indicating that it was being asked for clipboard data when it wasn't expecting to be so queried. I take that to mean that the secondary clipboard is intended to be used for data from outside of the local environment.
   Interesting, "secondary" is the only one that applications rarely ever touch.
   So this one will be set when the windows client copies something, and should not be updated thereafter - this may well lead me to the source of the problems.
   Could be a race since we set all three clipboards' ownership asynchronously.

4. Windows also seems to have an "undo" clipboard somewhere, which occasionally seems to confuse matters if clipboard contents don't "initialize" when an xpra session starts, in which case- despite having recently copied something from the windows client environment (before beginning the xpra session), an attempt to paste into the xpra will paste no data... and if one then tries to paste back into the windows environment something random will be pasted (which may or may not be drawn from the windows "undo" clipboard in much the same way that pasting sometimes results in pulling "deleted" data from the primary clipboard).
   Again, I don't know anything about this "undo" clipboard..
   Initialization is tricky, who owns the clipboard at that point is not clear. IIRC, at the moment, the client should own it.

In general:

1. If all three clipboards have data then most likely the last copy was from the client.
   That would make sense since any copy events from the client sets all 3 clipboards as owned by the client.

2. If the primary and clipboard clipboards have data, then the last copy was from within the xpra environment.
   Also makes sense, X11 applications only interact with those two.

3. If only the primary clipboard has data, then most likely there was a recent deletion.
   What is a "deletion"?

4. If the data in the primary clipboard and the clipboard clipboard are different, the clipboard will generally have the latest "copy data" while the primary will have the "delete data".
   Hmmm, that I am not sure about at all.
   Applications control the clipboards and they can place anything they like in there at any point.
   We are only meant to grab all the updates and forward them to the client, so the client should always have the last clipboard update made.

Unfortunately, the behavior is just buggy enough to resist a clear understanding or predictability.
Indeed.

Let's see if fixing (2)a and/or (3) leads anywhere.
Have you tried any of those tests with a simple xterm instead of chrome to rule out application specific behaviour?

[totaam]

2013-03-08 14:19:11: antoine uploaded file clipboard-tool.png (109.5 KiB)

screenshot of the new clipboard debugging tool

[totaam]

2013-03-08 14:56:24: antoine commented

---

r2913 adds a clipboard debugging tool, and here is a screenshot:
[[Image(http://xpra.org/trac/raw-attachment/ticket/272/clipboard-tool.png)]]

---

Hopefully this can help figure out what is going wrong.
There is a new MS Windows beta package which includes this new tool (named GTK_Clipboard_Test.exe on win32)

Some initial notes and explanations

• For each type of clipboard (CLIPBOARD, PRIMARY and SECONDARY), the top line is for retrieval and the bottom one for setting.
• The Targets options for retrieval starts empty, you first need to Get Targets to obtain the list of available targets. Only then can you call Get Target. You should probably refresh it whenever the selection owner changes, as calling Get Target on an invalid target simply returns an empty value.
• when using the Set String button, the data is copied from the editable field immediately, whatever text is in it at the time - changing the editable field afterwards does not have any effect until you use Set Target or Set String again. The only messages shown are:
  • Got string selection data.. (when using Get String), or:
  • Got selection data: ... (when using Get Target).
• when using the Set Target button, nothing really happens yet and you can continue to type into the text field, everytime you click on Get Target or Get String, the value is requested and you should see a Answering selection request with value: .... The value retrieved should then be displayed. The same message is also displayed when we own the selection and an application requests the clipboard data from us.
• The clear buttons have no other effect than to clear the fields (well, except when the text being cleared is already highlighted on Linux, as this text is automatically stored in PRIMARY.. so clearing it will also clear the selection)

• running on win32 without xpra and with just a notepad++ instance, it seems to provide data as "UTF8_STRING" only and we can grab it without problems with both Get Target and Get String, however when we try to use Set Target notepad++ does not seem to be aware that we offer the selection (using STRING or UTF8_STRING makes no difference). Using Set String always works though.

• on Linux, you may get extra "TARGETS", (like "TIMESTAMP") and the application tries to display the value it retrieves (it doesn't try too hard at present - this is just to test that we do get those values)
• on Linux, all 3 clipboards work as expected, with one exception: setting the PRIMARY clipboard target causes it to be requested again and again (see screenshot for example). It may be a misbehaving application doing some polling, this needs testing with lighter/minimal DEs to confirm.

[totaam]

2013-03-08 19:23:40: afarr commented

---

By "undo" clipboard I was referring to a buffer that is used when you right-click and select the undo option from the resultant drop-down menu. Since the primary stores selected data, I presumed that it was being used for this drop-down menu option. I still can't really think of any other reason to store selected data, either- especially before it is copied.

I failed, though to divorce the selecting of the data from the deleting of it (I guess I never thought to try that), so any reference I make to "deleting" data should be understood as being an assumed part of any selecting that is not a precursor to copying. Hence, a reference to a "recent deletion" is in fact a reference to a recent selection (with an anecdotal deletion of said selected data to follow, inconsequentially).

I should note, however, that in one instance of my testing I did inadvertantly paste blank data over a selected portion of text, deleting it but storing it in the primary clipboard... after which I used the right-click undo button to "restore" the data, in the process of which the primary was in fact cleared. I didn't repeat the process however, so I can make no estimation of how consistently it does this.

I should also note that the client's local clipboard seems to be another entity entirely from the clipboards of the xpra server (which you probably realize, but it seems like it should be said). Many times what is pasted in the windows client bears no resemblance whatsoever to the current contents of any of the three clipboards within the server.

In any case, I'll see if these new tools help me pin things down any more.

[totaam]

2013-03-09 03:30:40: afarr commented

---

Ok, still using a Fedora 18 server with xpra 0.9.0 but now with win client 0.8.8 I had some different results which might shed some light on... something.

1. With 0.8.8 client, a copy only seems to save to primary. Unfortunately, pasting to the xpra chrome browser seems to only use the clipboard... so the 0.8.8 client can't copy and paste from the client to an xpra chrome browser.

2. Xpra xterm windows, however, copy to and from the primary, so anything copied from a win client can be "pasted" (Shift-Inserted) into an xterm.

3. Xpra chrome browser copy (of highlighted text) copies to both primary and clipboard. Highlighting copies to primary, whether or not a copy operation is performed. Anything highlighted thusly can be inserted into an xterm window.

4. Oddly, whatever is "owned" by the windows clipboard seems to be loaded into the primary clipboard when an xpra session begins. The first change of the contents of primary seems to be pasteable to the win client, but later changes are (generally) not acknowledged by the client clipboard operations. Sometimes, however, only a portion of that first change will be "acknowledged" by the win client. One letter. Three letters. 17 letters. Sometimes different numbers of characters from the same string... and sometimes (very occasionally) it will change for no apparent reason. (Ownership issues? Some portion of primary clipboard data "wins a race" over ownership issues? I have no idea.)

5. Changes to primary can be made from selecting in chrome or in xterm and are equally likely (or rather, unlikely) to be acknowledged by win client.

6. For client clipboard copying to be pasteable to a chrome browser it needs to be picked up by clipboard. For xterm it needs to be picked up by primary. The loading of all three in 0.8.7 seemed to work well for client to server. (Perhaps I just needed to use the binding command.)

7. At one point selecting text in xpra chrome browsers was copying to the primary, but then hitting backspace was clearing primary. I can only guess that something caused the clipboard to copy the "blank" as if it were "selected" to the primary. It behaved this way consistently, until I stopped that xpra session. The three subsequent xpra sessions however did not clear the primary with backspaces of highlighted text.

8. While the primary was being cleared by backspaces, inserting into an xterm pasted in whatever was in the primary before the last selection which was deleted by the backspace. This consistently occurred, with xterm insertions pasting in data that was no longer contained in any of the three clipboards. (Perhaps xterm has yet another "insertion clipboard" that it turns to if the primary has recently been cleared? Perhaps my server picked the wrong morning to quit sniffing glue?) Once the backspacing ceased clearing primary this behavior also ceased.

9. Whatever I did, I could not find any correlation between secondary or clipboard with anything that successfully pasted into the win client. primary had some success, but very limited. IIRC testing with 0.8.7, when copying from the win client was stored in all three clipboards, had the effect of "renewing" the ability for things copied in an xpra browser to be pasted into the win client. I'm not sure if it was a coincidence, but perhaps the updating of the secondary by a win client copy operation then caused a reaction to the next primary change "similar to that seen when an xpra session first begins" which allows for the next "change" in the primary to be passed to the client?? (I realize that makes little sense, but perhaps there is some ownership issue that the use of the secondary "toggles"... and, judging from the fact that I saw pastings with no change in clipboard, I suspect it is primary that has some success being "read" by a window client)

Hopefully this is some use.

[totaam]

2013-03-09 03:39:18: antoine commented

---

When testing with 0.8.x, the clipboard uses the old code which selects a single target for the data exchanges (PRIMARY by default - though this can be changed via the tray menu). This explains most of what is reported in comment:7.
(that and the bugs: (2)a and (3) from comment:3)

I don't think we will fix anything in the 0.8.x branch, it doesn't work great (and maybe the default remote clipboard should be CLIPBOARD instead of PRIMARY, this would make most people happier, except me an my xterms.. - but otherwise I think it works as was expected given the code that is in there) - 0.9.x is where it's at.

[totaam]

2013-03-19 14:28:19: antoine commented

---

• Trying to understand (2)a:

• on client connect, server gets all 3 tokens:

got token, selection=CLIPBOARD
got token, selection=PRIMARY
got token, selection=SECONDARY

• setting the contents of PRIMARY clipboard on the server end (using copy from somewhere, here I used set STRING target for CLIPBOARD selection from the clipboard tool, with a value of "123"), this showed on the server:

do_selection_clear_event(.. GDK_SELECTION_CLEAR selection=CLIPBOARD, target=, property=>) selection=CLIPBOARD
send clipboard token: CLIPBOARD
process clipboard packet type=clipboard-request
process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=UTF8_STRING
get_contents(UTF8_STRING,<function got_contents at 0x7f2c1c85f500>) selection=CLIPBOARD
unpack: <type 'NoneType'>, 0
unpack(..) type=, format=0, data=<type 'NoneType'>:0
got_contents(, 0, <type 'NoneType'>:0) str(data)=None..

So, we claim the CLIPBOARD selection, send the token to the client, the client then requests the contents as a 'UTF8_STRING' and we send back nothing...
The client showed:

got token, selection=CLIPBOARD
do_selection_request_event(... selection=CLIPBOARD ..)
target for CLIPBOARD: UTF8_STRING
get clipboard from remote
got clipboard contents None
remote selection fetch timed out or empty

Questions:

• why did the win32 client immediately request the contents of the clipboard? what application? (how can we even find out?)
• why didn't we find a value for the contents, since I set it to '123'..

• reverse test: setting clipboard from win32
• sends all the tokens to the server
• requesting targets from the server correctly causes the client to call:

get_contents(TARGETS, ..)

• client returns an empty value??

This is giving me a headache! I'll try again tomorrow, but it looks like even the solution of going back to the one-to-one mapping may have the same issue..

[totaam]

2013-03-22 13:17:57: totaam commented

---

• AFAICT win32 always requests the contents of the clipboard as soon as we set targets, so syncing with PRIMARY is out of the question. So we remove the merged clipboard code and we have to claim ownership (send the anti-token) of the clipboard everytime we get new data to ensure that the server will send the new data when something else is copied to the clipboard. (the code is not pretty, but this was easier than subclassing or adding new signals - probably)

• Next problem was to do with targets, on *nix we were looking for atoms using the standard selection code, but this doesn't work on win32. Fortunately gtk has a nice function for getting targets already request_targets - unfortunately, that doesn't fit very well with the raw-to-wire and wire-to-raw methods.. so a lot of changes to accomodate that were needed too.

• Third, we now sync with CLIPBOARD and not PRIMARY on win32 clients since that's what most people expect.. (never mind my xterms..)

---

Changes are in r3038

---

How to test (steps most likely to exercise the fixes):

• copy text in application running via xpra
• paste into native application
• copy more text in application running via xpra
• paste into native application again (verify the new text shows up)
  Then as above but reversed (though that was not a problem for me before)

---

Rants and notes:

• maybe we could use a flag (possibly named "crappy win32 platform"?) to tell the server to send the client something when the selection changes as we do seem to be getting an event when that occurs:

do_owner_changed((<gtk.Clipboard object at 0x2a35b40 (GtkClipboard at 0x2a32820)>, \
    <gtk.gdk.Event at 0x29ad260: GDK_OWNER_CHANGE \
    reason=GDK_OWNER_CHANGE_NEW_OWNER, selection=CLIPBOARD>))

But this wouldn't save us much since the big waste (often transferring clipboard contents before they are needed) cannot be avoided on win32.

• we should probably add a client capability so we can tell the server not to bother with PRIMARY and SECONDARY clipboards when only win32 clients are connected. (and save wasted CPU and bandwidth)

[totaam]

2013-03-23 05:54:57: totaam commented

---

r3039 removes the ability to select the "old" merged clipboard from the tray menu, the "merged" clipboard code no longer exists.

[totaam]

2013-03-25 19:56:04: afarr commented

---

I rebuilt a fedora 0.9.0 xpra and installed it server-side (3/25/13, built from svn source, said it included 3039). I am using the 0.9.0 windows client from beta 3/22/13. Testing with gtk_view_clipboard on xterms and google-chrome browser in xpra session.

Results:

• Test 1

http://www.foiledcupcake.com (all 3 clipboards)
(select text in xterm)
(Primary: owner changed, reason: new owner, new owner = 0x80001b)
--->clipboard clear (got string selection data: '')
-->primary happy happy fu (Got string selection data: ' happy happy fu')
--> secondary clear (Got string selection data: '')

Paste in txt
 happy happy fu
(straight from primary)

• Test 2: Type & select new text in xterm

Primary : Owner changed, reason: new owner, new owner=0x80001b

---> Clipboard clear (Got string selection data: '')
--> Primary (Got string selection data: ' command not found') {Selected}
--> Secondary : (Got string selection data: '')

This is as reproducible as a fecund teenager.

• Test 3: Type virii into xterm & select.

Primary : Owner changed, reason: new owner, new owner = 0x80001b
Clipboard: (Got string selection data: '')
Primary: (Got string slection data: ' virii')
Secondary: (Got string selection data: '')
Paste:  happy happy fu (old clipboard data)

• Test 4:
  Copy something client-side to reset clipboard. ('old clipboard data')
  Select 'virii' from xterm. Paste (' virii')

Clipboard: (Got string selection data: '')
Primary: (Got string selection data: ' virii')
Secondary: (Got string selection data: '')

Paste into browser.
--nothing--

• Test 5:
  Type 'virii' into browser, select & copy.

"clipboard buffer contains blacklisted pattern 'virii' and has been dropped!"
Clipboard: (Got string selection data: 'virii')
Primary: (Got string selection data: 'virii')
Secondary: (Got string selection data: '')

Paste in txt: ('')

• Test 6:
  Type something else into browser & select & copy. Paste ('')
  Copy something client side to reset clipboard, then select & copy browser text. ('unhappy camper')

--->Clipboard: (Got string selection data: 'unhappy camper')
--> Primary: (Got string selection data: 'unhappy camper')
--> Secondary: (Got string selection data: '')

• Test 7:
  Select something from xterm. Paste ('unhappy camper')

--->Clipboard: (Got string selection data: 'unhappy camper')
--> Primary: (Got string selection data: ' :ApplyCaretV')
--> Secondary: (Got string selection data: '')

• Test 8:
  Copy something client-side to reset clipboard.

---> Clipboard: Owner changed, reason: new owner, new owner=0x400020
--> Primary: Owner changed, reason: new owner, new owner=0x400021
--> Secondary: Owner changed, reason: new owner, new owner=0x400022

(All 3 clipboards set to client-side copy data)

• Test 9:
  Now select from xterm (Paste: 'nted reached')

--> Primary: Owner changed, reason: new owner, new owner=0x80001b
Paste again: 'nted reached'
--->Clipboard: Got string selection data: ''
--> Primary: Got string selection data: 'nted reached')
--> Secondary: Got string selection data: ''

[totaam]

2013-03-28 18:47:58: antoine commented

---

I was finding it very hard to read, understand and respond to comment:13, so I have edited the text to try to make it easier to refer to it (adding numbering) - apologies if I've somehow misinterpreted anything. In the future, please try adding: expected: X, result: Y and copying easily identifiable strings rather than random bits of text (ie: is "foiledcupcake" relevant in any way? does it help us understand/identify what we are looking at or what is expected to happen)

• First things first, what does the clipboard menu in the system tray show as options and which one is selected?

[[BR]]

• Test 1: Paste in txt - I assume this means pasting into a client side text editor, it looks like old xpra code as this should not be possible with current trunk - XPRA_CLIPBOARD_DEBUG=1 log samples (preferably from both sides) would help us confirm what is happening here.

• Test 2: It seems that a number of these tests, at least this one AFAICT, are done using the clipboard tool and an application (xterm or chrome) with both running on the same side (server side), which is something that is not and never will be filtered in any way by xpra. Reproducible this should be, since this is the correct/expected X11 behaviour.
• Test 3: Looks exactly as expected to me?
• Test 4: Same issue "Test 1" above, the browser pastes from "clipboard" not "primary".
• Test 5: the blacklisted contents get dropped... So we're testing both the filter and copy&paste issues at the same time (no wonder I was confused!).
  r3045 should help in this case (and when copying an empty string) as we now always force claim the selection, no matter what the contents received are. This should prevent the need to "reset the clipboard" by copying something client side (by virtually "copying" something every time something is received).
• Test 6: Apart from the "reset clipboard" issue above, I assume this works as intended?
• Test 7: not sure what the strings are meant to be, I assume this works as intended?
• Test 8: All 3 clipboards set to client-side copy data - how did you verify this? If true, this seems to do something that is simply impossible with the current clipboard code, and makes me think that the version tested is not the correct and up to date one, if not debug logging could shed a light on this. r3039 even removes the code from the tree to make sure - please verify with the latest from trunk. (please also see the "initial" question above too)
• Test 9: not sure how where things are pasted or what is/isn't expected here.

[totaam]

2013-03-30 03:00:38: afarr commented

---

Firstly, you are correct. The text I used was irrelevant, with the exception of "virii".

I just rebuilt xpra 0.9.0 for fedora (got notification of 3046 during the svn update) and I am using the 0.9.0 xpra beta for windows client (downloaded 3/26/13).

I just repeated test 1: and I am still able to copy from an xterm (opened as a start-child on the server command line) to a client side txt file.

The behavior is similar to any other xpra-session to window client copy & pasting. The second set of text I selected (xterm copy), when I attempted to paste it into a windows client txt file I instead re-pasted the text from the first copy (select). Once I do a (pointless) copy on the client side, however, then the next selection in an xterm is likewise pasteable.

Test 2. was a repetition of the test, and the test is still repeatable as far as I can tell.

Tests 3,4&5. Were tests of the clipboard filter. We can forget about them.

Test 6 was merely to show that a copy from a browser was copying to both primary & clipboard (which I suspected but wanted to see).

Test 7 was to show that copy (select) from an xterm was solely copying to primary (as we would expect). It did indeed change contents of primary and did indeed NOT change contents of clipboard.

Test 8 was a documentation of the change of owner of all three clipboards when a copy was made client-side (which I hadn't expected, but which doesn't surprise me). I verified it by looking at the contents of the gtk_view_clipboard data and comparing it with the output of a control-V in a client-side txt file. Repeating, I get the same results.

debugging log:

clipboard raw -> wire: ('UTF8_STRING', 8, 'skadoopie\x00') -> ('bytes', 'skadooopie\x00')
process clipboard packet type=clipboard-pending-requests

(Note, I tested this after the Test 9 logs were generated, so the 'skadoopie' mentioned is a reference back to the previous contents, presumably.)

Test 9 was to see what happens to clipboards server-side when a copy is made from an xterm after all three clipboards were changed by the client-side copy. I was surprised to see clipboard and secondary both cleared. I was expecting to see the change in primary.

With the latest (as far as I can tell) server-side fedora and client side windows install- I still seem to be able to copy from an xterm to a client-side txt file (or anything else, really).

The client-side XPRA_CLIPBOARD_DEBUG=1 is telling me the following:

get clipboard from remote handler id=1
local_to_remote(CLIPBOARD) current_remote_clipboard=PRIMARY
process clipboard packet type=clipboard-contents
process clipboard contents, selection=PRIMARY, type=UTF8_STRING, format=8
_munge_wire_selection_to_raw(bytes, UTF8_STRING, 8, (type 'str'):10:[' ', 's', 'k', 'a', 'd', 'o', 'o', 'p', 'i', 'e'])
wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data0=10
clipboard wire -> raw: ('UTF8_STRING, 8, 'bytes', ' skadoopie') -> ' skadoopie'
got clipboard contents91)=10 (type=UTF8_STRING, format=8)
get clipboard from remote result(1)={'data': ' skadoopie', 'type': 'UTF8_STRING', 'format': 8}
do_selection_get((GtkSelectionData at 0x18ef2c),0,0) calling selection_data.set(UTF8_STRING, 8, (type 'str'):10)

I hope this clarifies something. I will try to go through the fedora server and look for any and all possible other instances of xpra that might be hiding high or low and confusing the yum localinstall when I get a chance, but I think I got them all already.

[totaam]

2013-03-30 08:54:39: antoine commented

---

The log messages you just posted confirm what I suspected all along:

local_to_remote(CLIPBOARD) current_remote_clipboard=PRIMARY

This message was part of the merged clipboard, which has been removed in r3039.

[[BR]]

You can verify that this code is no longer present in the source tree:

$ grep -r current_remote_clipboard ./trunk/src | wc -l
0

[[BR]]

You should be using your own build system to make new win32 installers as needed, otherwise you have to wait for me to upload new ones - like this one I built yesterday:

4cb7e3dbefc710d7860512d21bd768a5  Xpra_Setup_0.9.0.exe