xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#459 closed defect (fixed)

Null character gets added to the end of clipboard contents while copying from MS Windows

Reported by: AndrewZ Owned by: Antoine Martin
Priority: major Milestone:
Component: client Version: 0.10.x
Keywords: clipboard, Cc:

Description

Both client and server versions are 0.10.9, as indicated by 'About' window and 'xpra --version'.

So, when I do, for example, Win+R -> type 'notepad' -> Ctrl+A -> Ctrl+C, then on my virtualboxes' Ubuntu 13.10 putty command prompt execute

$ xclip -o -selection clipboard | cat -v

, I get

notepad^@

which seems to me to be the case of off-by-one-error. So, I'm no expert in X protocol, but if saving clipboard contents requires putting length of the contents, could you please just decrement it by one?

Change History (12)

comment:1 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Thanks for the report - it's embarrassing that I never spotted this before, despite using the "GTK_Clipboard_Tool.exe" extensively for clipboard testing! (this is not an off-by-one error)

Here is some debugging collected with:

XPRA_CLIPBOARD_DEBUG=1 xpra ...

I am only including client-side logs as the server doesn't do anything clever with this data.


Here's what happens client side on win32:

  • when I copy the text ("hello") to the clipboard:
    do_owner_changed((<gtk.Clipboard object at 0x21867b0 (GtkClipboard at 0x1017078)>, \
        <gtk.gdk.Event at 021850E0: GDK_OWNER_CHANGE reason=GDK_OWNER_CHANGE_NEW_OWNER, selection=CLIPBOARD>)) \
        greedy_client=False, block_owner_change=False
    
  • when I request the clipboard contents using xclip:
    process clipboard packet type=clipboard-pending-requests
    process clipboard packet type=clipboard-request
    remote_to_local(CLIPBOARD) local_clipboard=CLIPBOARD, remote_clipboard=CLIPBOARD
    process clipboard request, request_id=0, selection=CLIPBOARD, local name=CLIPBOARD, target=UTF8_STRING
    get_contents(UTF8_STRING,<function got_contents at 0x0218A130>) selection=CLIPBOARD
    unpack <gtk.Clipboard object at 0x21867b0 (GtkClipboard at 0x1017078)>: <type 'gtk.SelectionData'>
    unpack: <GtkSelectionData at 0x109a400>
    unpack(..) type=UTF8_STRING, format=8, data=<type 'str'>:6
    got_contents(UTF8_STRING, 8, <type 'str'>:6) data=0x68656c6c6f00..
    _do_munge_raw_selection_to_wire(UTF8_STRING, UTF8_STRING, 8, <type 'str'>:6)
    clipboard raw -> wire: ('UTF8_STRING', 8, 'hello\x00') -> ('bytes', 'hello\x00')
    process clipboard packet type=clipboard-pending-requests
    
    So it looks like the string we get when we request the data in UTF8_STRING format claims to be 6 characters long, which includes the null byte at the end.

Doing the same thing from a Linux client:

  • copying "hello" using gedit:
    do_owner_changed((<gtk.Clipboard object at 0x37da730 (GtkClipboard at 0x381cca0)>, \
        <gtk.gdk.Event at 0x37d3148: GDK_OWNER_CHANGE reason=GDK_OWNER_CHANGE_NEW_OWNER, selection=PRIMARY>)) \
        greedy_client=False, block_owner_change=True
    
  • then when I request the data using xclip:
    process clipboard packet type=clipboard-pending-requests
    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 0x37e4758>) selection=CLIPBOARD
    unpack <gtk.Clipboard object at 0x37da5a0 (GtkClipboard at 0x381cc20)>: <type 'gtk.SelectionData'>
    unpack: <GtkSelectionData at 0x2b85080>
    unpack(..) type=UTF8_STRING, format=8, data=<type 'str'>:5
    got_contents(UTF8_STRING, 8, <type 'str'>:5) data=0x68656c6c6f..
    _do_munge_raw_selection_to_wire(UTF8_STRING, UTF8_STRING, 8, <type 'str'>:5)
    clipboard raw -> wire: ('UTF8_STRING', 8, 'hello') -> ('bytes', 'hello')
    
    And so GTK on Linux clients does the right thing and does not include the null byte in the UTF8_STRING...
  • same thing with Mac OSX clients: the strings we get are the correct length and do not include the terminating null byte.

I don't like blindly truncating the UTF8_STRING on win32 as this is just an encoding and applications may use UTF8 to transfer data that does have null bytes in it, including at the end of the string.. Just as bad to make this workaround conditional on a specific platform..
But since I can't think of a better solution, r4773 does exactly that.

I will backport this to v0.10.x

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Applied to v0.10.x in r4774. Closing, feel free to re-open if I've missed anything.

comment:3 Changed 6 years ago by AndrewZ

Thanks for quick reply and specially for backporting :-)

Last edited 6 years ago by AndrewZ (previous) (diff)

comment:4 in reply to:  1 Changed 6 years ago by AndrewZ

Replying to totaam:

I don't like blindly truncating the UTF8_STRING on win32 as this is just an encoding and applications may use UTF8 to transfer data that does have null bytes in it, including at the end of the string.. Just as bad to make this workaround conditional on a specific platform..
But since I can't think of a better solution, r4773 does exactly that.

I'll just put here an advice to report a bug to GTK developers - it's there responsibility from what I've understood.

comment:5 in reply to:  2 ; Changed 6 years ago by AndrewZ

Replying to totaam:

Applied to v0.10.x in r4774. Closing, feel free to re-open if I've missed anything.

Can you please also build it and upload?

comment:6 in reply to:  5 Changed 6 years ago by AndrewZ

Replying to AndrewZ:

Replying to totaam:

Applied to v0.10.x in r4774. Closing, feel free to re-open if I've missed anything.

Can you please also build it and upload?

I mean, I know it's Python, but I could not find clipboard_base.py on Windows.

comment:7 Changed 6 years ago by Antoine Martin

I'll just put here an advice to report a bug to GTK developers - it's their responsibility from what I've understood.

It is, but since they've abandoned GTK2 (no updates for almost 2 years) and seem to ignore bug reports, I won't bother :(

Can you please also build it and upload?
I mean, I know it's Python, but I could not find clipboard_base.py on Windows.

py2exe creates a zip file named library.zip which contains all the python bits.


If you cannot wait for the upcoming 0.10.10 release, there are 0.11.0 beta win32 packages with the fix here (and 0.11 is now stable enough for day to day usage - also getting close to a release)

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:8 in reply to:  7 Changed 6 years ago by AndrewZ

Replying to totaam:

It is, but since they've abandoned GTK2 (no updates for almost 2 years) and seem to ignore bug reports, I won't bother :(


Maybe people from MUTTER project could help? Or do they also use GTK3?

If you cannot wait for the upcoming 0.10.10 release, there are 0.11.0 beta win32 packages with the fix here (and 0.11 is now stable enough for day to day usage - also getting close to a release)


Thanks again!

comment:9 Changed 6 years ago by AndrewZ

Actually 0.11.0 isn't working for me at all. I connect through ssh, then no windows are shown, still plink is running (spawned by Xpra launcher process). Does it require newer beta server than that I see on xpra.org/beta/saucy?

Last edited 6 years ago by AndrewZ (previous) (diff)

comment:10 Changed 6 years ago by Antoine Martin

Actually 0.11.0 isn't working for me at all

Oh snap!

Does it require newer beta client than that I see on xpra.org/beta/saucy?

The new client I uploaded was for win32, the saucy beta packages are much older. You should not need a new server to try the new win32 client though.

comment:11 Changed 6 years ago by AndrewZ

That's bad... Some advice to collect info?

comment:12 Changed 6 years ago by Antoine Martin

Advice: yes, the usual:

  • xpra info on server
  • client connection from command line with "-d all"
  • test *nix client with same server

etc..

(in a new ticket please)

Note: See TracTickets for help on using tickets.