xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 5 days ago

#1458 closed defect (fixed)

Clipboard is unreliable with thunderbird editor area

Reported by: psycho_zs Owned by: psycho_zs
Priority: minor Milestone: 2.0
Component: clipboard Version: trunk
Keywords: Cc:

Description

Running thunderbird on server, copying or pasting text from/into thunderbird's editor area not working most of the time.

In the test I've copied text from leafpad on the client to leafpad on server (successful), then another text from leafpad on the client to thunderbird on server (previous data is pasted). Then again (unsuccessful), then pasted to leafpad on server (successful), then pasted to thunderbird (after pasted to leafpad, successful).

So after using clipboard for the first time, I'm only being able to paste to thunderbird after I paste to something else.

Attachments (4)

client_clipboard.log (139.3 KB) - added by psycho_zs 3 months ago.
server_clipboard.log (322.1 KB) - added by psycho_zs 3 months ago.
clipboard_client.log (24.9 KB) - added by psycho_zs 7 weeks ago.
isolated copy+paste
clipboard_server.log (61.6 KB) - added by psycho_zs 7 weeks ago.
isolated copy+paste

Download all attachments as: .zip

Change History (11)

Changed 3 months ago by psycho_zs

Attachment: client_clipboard.log added

Changed 3 months ago by psycho_zs

Attachment: server_clipboard.log added

comment:1 Changed 3 months ago by Antoine Martin

Component: clientclipboard
Milestone: 2.0
Status: newassigned

From the log samples: xpra X11 version 2.0-r15223 64-bit on Linux Debian 9.0 stretch.

Oh god, another clipboard bug..

comment:2 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs
Status: assignednew

I cannot reproduce.
The clipboard works for me everytime, in both directions.
I've tried on Fedora 25 and Debian Stretch.

Maybe something is interfering with the clipboard on your client system? See wiki/Clipboard.

I cannot use the sample log files provided as I have no way of knowing which part of the log file relate to what: the communication is done via the X11 server's "selections", so all the events look pretty much the same.

comment:3 Changed 7 weeks ago by Antoine Martin

Please provide more succinct or annotated log samples, otherwise I will have to close this ticket as "worksforme".

comment:4 Changed 7 weeks ago by psycho_zs

I've isolated two events: I copy text from leafpad on client and unsuccessfully try to paste it into thunderbird on server. No clipboard manager running. Copied text was: 2:36: copy from leafpad client to tb server
Attaching this part of server log and client output...

Changed 7 weeks ago by psycho_zs

Attachment: clipboard_client.log added

isolated copy+paste

Changed 7 weeks ago by psycho_zs

Attachment: clipboard_server.log added

isolated copy+paste

comment:5 Changed 7 weeks ago by Antoine Martin

OK, so that's quite a bit clearer.
We see lots of:

process clipboard request, request_id=11, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS

That's the application requesting the list of targets for the clipboard. (the list of formats we can supply for this clipboard)

We dutifully respond every time with the list:

['TIMESTAMP', 'TARGETS', 'MULTIPLE', 'GTK_TEXT_BUFFER_CONTENTS', \
    'application/x-gtk-text-buffer-rich-text', 'UTF8_STRING', 'TEXT', 'STRING',  \
    'text/plain;charset=utf-8', 'text/plain']

But then we get a request that doesn't make any sense:

process clipboard request, request_id=14, selection=CLIPBOARD, local name=CLIPBOARD, target=application/x-moz-nativehtml

As it uses a target ("application/x-moz-nativehtml") we have not advertised.
And when forward it to the application, it responds with "no data":

unpack(..) type=, format=0, data=<type 'NoneType'>:0

Which is expected since we're requesting a target it knows nothing about.

And this rings a bell:

The patch above was not applicable as it is: some applications may provide the "x-moz-nativehtml" target, so we should only translate this target if it isn't going to work.
r15589 does that, it also exposes the targets we have last sent via xpra info:

$ xpra info | grep last-targets

@psycho_zs: does that work for you now?

Last edited 7 weeks ago by Antoine Martin (previous) (diff)

comment:6 Changed 3 weeks ago by Antoine Martin

Not heard back, closing.

comment:7 Changed 5 days ago by Antoine Martin

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.