#2403 closed defect (fixed)
Windows client highlighting text in gedit window can disable clipboard.
Reported by: | alas | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 3.0 |
Component: | clipboard | Version: | 3.0.x |
Keywords: | Cc: |
Description
Still testing the clipboard a little with Windows client 3.0-r23707, against 3.0-r23689 server on Fedora 30, I noticed some odd warning messages (possibly expected) when pasting into a gedit window.
2019-09-05 12:40:13,220 client is requesting an unknown target: 'GTK_TEXT_BUFFER_CONTENTS' 2019-09-05 12:40:13,221 valid targets: text/plain, text/plain;charset=utf-8, UTF8_STRING 2019-09-05 12:40:13,221 dropping the request
Some permutation (maybe highlighting something, then highlighting something else and copying, then pasting into gedit?) was giving a slightly different warning.
2019-09-04 13:08:34,136 Warning: CLIPBOARD selection request for 'UTF8_STRING' timed out 2019-09-04 13:08:34,137 request 18 at time=0
And at some point in the testing I also triggered something client side, but I'm not sure what it was (traceback, might be easy to find and address?).
Traceback (most recent call last): File "./xpra/client/gtk_base/gtk_client_window_base.py", line 1985, in do_unma p_event NotImplementedError: virtual method Gtk.Widget.unmap_event not implemented
While trying to pin down all these details though, I discovered I can easily trigger a warning about more than 30 clipboard requests per second simply by highlighting a small portion of text in a gedit window in the session... and if I don't notice the warning quickly enough (3 seconds I guess), then I can (and did) disable the clipboard entirely.
2019-09-05 12:47:31,436 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:31,456 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:35,399 Warning: PRIMARY selection request for 'UTF8_STRING' timed out 2019-09-05 12:47:35,399 request 170 at time=0 2019-09-05 12:47:57,836 Warning: more than 30 clipboard requests per second! ... 2019-09-05 12:47:59,570 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:59,590 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:59,602 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:59,622 Warning: more than 30 clipboard requests per second! 2019-09-05 12:47:59,622 limit sustained for more than 3 seconds, 2019-09-05 12:47:59,622 the clipboard is now disabled 2019-09-05 12:47:59,629 client 2 @05.256 clipboard toggled to off by the server, reason given: 2019-09-05 12:47:59,634 client 2 @05.259 more than 30 clipboard requests per second!
And, while I can apparently use the menu to 'double disable' the clipboard, there's no mechanism to re-enable it.
2019-09-05 12:49:59,182 client 2 @04.804 unknown string message: 0xc241L / 0x52 / 0x46 2019-09-05 12:49:59,184 client 2 @04.806 unknown string message: 0xc241L / 0x50 / 0x0 2019-09-05 12:50:11,133 client 2 @16.753 clipboard synchronization direction changed to: disabled 2019-09-05 12:50:30,166 client 2 @35.784 server clipboard synchronization changed to CLIPBOARD selection 2019-09-05 12:50:30,166 Warning: unexpected clipboard packet 2019-09-05 12:50:30,167 clipboard is disabled for 731790b2e835c5605eb26c9fd4c4a1b1c0268390 2019-09-05 12:50:30,171 client 2 @35.788 server clipboard synchronization changed to CLIPBOARD selection 2019-09-05 12:50:30,173 Warning: unexpected clipboard packet 2019-09-05 12:50:30,174 clipboard is disabled for 731790b2e835c5605eb26c9fd4c4a1b1c0268390
But, in the process of trying to re-enable, I triggered the client side error again (maybe that helps?)
2019-09-05 12:50:14,284 clipboard synchronization direction changed to: disabled 2019-09-05 12:50:33,317 server clipboard synchronization changed to CLIPBOARD se lection 2019-09-05 12:50:33,320 server clipboard synchronization changed to CLIPBOARD se lection Traceback (most recent call last): File "./xpra/client/gtk_base/gtk_client_window_base.py", line 1985, in do_unma p_event NotImplementedError: virtual method Gtk.Widget.unmap_event not implemented
(now to get back to the point of #1844...)
Change History (2)
comment:1 Changed 17 months ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 5 days ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2403
GTK applications do that: they request targets that don't exist...
So we drop them and log a message.
Timeouts should be rare, and they should be handled gracefully enough.
Let's re-open if this causes problems.
That's a weird one. The window class should always handle unmap events.
I've tried to reproduce it but I just cannot hit it. (unmap is usually triggered when the window is iconified or moved to another desktop)
From now on, we'll log it with better details at error level: r23722.
In any case, I don't think this is too much of a problem.
We no longer disable the clipboard when getting many requests: r23723.
Though we should handle this better and just rate limit them: #2404.
There is, but it is well hidden. Because the clipboard is disabled server-side, that's where you would have needed to re-enable it, using the
clipboard-direction
control command, or its dbus equivallent. (ie: change from "disabled" to "both")