Copying URL from web browser address bar on remote host fails

[totaam]

Issue migrated from trac ticket # 703

component: core | priority: major | resolution: worksforme | keywords: clipboard

2014-10-01 21:59:14: jiang.qian created the issue

---

Copying and pasting generally works fine from and to web browsers on remote machines.

However, when I try to copy URL from address bar of the remote host, not only it does not register on the local clipboard, but also the clipboard integration is entirely disabled. clicking on tray menu shows previously checked clipboard unchecked, and re-checking it fails to re-enable clipboard copying between local and remote host. Only disconnecting and reconnecting restore clipboard. Selected URL can, however, be copied to remote web browser itself.

This problem appears in both firefox and chrome running on remote host.

The error message on the client window is:

"/usr/lib/python2.7/dist-packages/xpra/gtk_common/nested_main.py:163: Warning: Source ID 87638 was not found when attempting to remove it
  gobject.source_remove(hard)"

Attached files show the information reported by bug report from tray menu

I'm running the latest xpra 0.14.8 on both server and client, the server running ubuntu 14.04 x86_64 and client running 14.04 32 bit.

[totaam]

2014-10-01 21:59:29: jiang.qian uploaded file xpra-bug-report.txt (21.0 KiB)

[totaam]

2014-10-01 22:11:34: jiang.qian commented

---

This problem is present when trying to copy URL from context menu of a web browser as well. For example. right-clicking a link on firefox running on remote machine and then select from popup menu "copy URL" will not work and disable clipboard integration for the rest of the session

[totaam]

2014-10-01 22:25:48: jiang.qian uploaded file xpra-bug-report.txt.zip (242.3 KiB)

[totaam]

2014-10-02 03:47:33: totaam changed owner from antoine to jiang.qian

[totaam]

2014-10-02 03:47:33: totaam edited the issue description

[totaam]

2014-10-02 03:47:33: totaam commented

---

That's odd, the clipboard got tested quite thoroughly.
Normally when it gets disabled is because we detect a loop, when another application is also synchronizing it, and we end up disabling it. But I would have expected a message to show up.

Can you post the clipboard debug log?
Run both the client and server with -d clipboard.

[totaam]

2014-10-02 06:44:29: jiang.qian commented

---

Yes, it did say something about the loop.
For what it's worth, I'm running on my local ubuntu machine clipboard manager parcellite. But I don't think it is the problem, since I change the clipboard manager to glipper the problem persist. If you have a ubuntu trusty (14.04) machine, perhaps you could reproduce it? It's a major annoyance here, since the more often use of clipboard exchange between host and client is exchanging URLs...

Anyway, thanks for looking into this!

Here's the message from debugging

2014-10-02 01:40:12,150 loop nesting too deep: 11
2014-10-02 01:40:12,150 you may have a clipboard forwarding loop, disabling the clipboard
/usr/lib/python2.7/dist-packages/xpra/gtk_common/nested_main.py:162: Warning: Source ID 520 was not found when attempting to remove it
  gobject.source_remove(soft)
/usr/lib/python2.7/dist-packages/xpra/gtk_common/nested_main.py:162: Warning: Source ID 515 was not found when attempting to remove it

[totaam]

2014-10-02 06:51:34: totaam commented

---

This is covered in the FAQ: Please make sure that you are not running a clipboard manager which may interfere with xpra's clipboard synchronization code (ie: klipper is known to cause such problems).

Clipboard managers are known to cause serious problems.
I guess what we could do is exit the nesting when we get a request for the clipboard contents whilst we are waiting for that request ourselves. But we would still be at the mercy of clipboard managers not doing crazy requests... and from past experience, that's a big assumption to make.
Until then, it is best to not use clipboard managers.

[totaam]

2014-10-02 07:55:38: jiang.qian commented

---

Unfortunately, I killed all clipboard manager, killed the connection, and reconnected, and the problem persists.

[totaam]

2014-10-02 08:18:31: totaam commented

---

Then something else is syncing clipboards, vmware or virtualbox perhaps.

I have added the warning message to the FAQ: FAQ changes no 62

[totaam]

2014-10-02 20:13:39: jiang.qian commented

---

I'm not running any virtual machine. Is there any way to figure out which program is the problem?

Furthermore, this is peculiar, since I'm not having problem with copy and paste in general. Copying and pasting from webpages by selecting text works. The only problem is selecting URLs, either from address bar, or by context menus. And this is not just for web browsers. For example, if I run gnome-terminal and select URL by context menu, this bug shows up, too.

To further debug, I disabled gnome url-handler related configurations in gconf, and disabled any clipboard manager. But the problem persists.

Any suggestion to further debug this would be much appreciated. It may well has something to do with url handler in gnome or some other desktop environments. If so, it would be helpful for other users to find out this as well!

By the way, thank you for being so responsive! And xpra really rocks! I've been searching a good thin-client agent to use on my local LAN for a long time, and xpra really solved all my problems with NX, forward X, vnc, etc, and the performance is simply terrific!

[totaam]

2014-10-03 04:40:29: totaam commented

---

Is there any way to figure out which program is the problem?
[[BR]]
Well, there is, but you're not going to like it: you have to stop every X11 program until you find the one that is causing the problem. Assuming that it isn't the browser itself. I guess you could start by running the browser under a minimal desktop like twm, and see if the problem still occurs.
[[BR]]

The only problem is selecting URLs, either from address bar, or by context menus.
[[BR]]
In a way, that's a good thing. I think at the very least we should be able to come up with a workaround.
[[BR]]

Any suggestion to further debug this would be much appreciated.
[[BR]]
You can run the client and server with -d clipboard and post the output.
[[BR]]

(..) xpra really rocks! (..)
[[BR]]
Thanks!

[totaam]

2014-10-03 07:22:19: jiang.qian commented

---

This got to be the single most bizarre bug I've ever seen! I followed your advice and installed openbox. The bug persists even in that very minimalist window manager(with no clipboard manager running, of course).

So it is a very persistent bug.

But then I have the strangest discovery. I began killing program I run one by one, to no avail.

Until I realize that it's my habit, as a commandline fanatic, to run 7-8 gnome-terminal instances. I found that I can only reproduce the bug when there are at least 5 gnome-terminal instances running. If I have 7-8 instances running, the bug is fairly consistently reproducible.
(Sometimes the copying URL problem does not appear on the first session. the copy and paste works fine. But disconnect and reconnect the bug will appear!

So far, it seems that as long as I run "only" four gnome-terminal instances, and use xterm for other terminals, I can run gnome-fallback and unity or any window manager, with clipboard manager parcellite running, and not affected by the bug.

If I got hit by the bug with 4 instances of gnome-terminal running, I'll report here again. But other than that, we can probably close this bug with a mysterious warning "don't run too many gnome-terminal simultaneously..."

[totaam]

2014-10-03 08:52:02: totaam commented

---

Ah, OK. That's very interesting.

That must be because they each make a request for the contents at the same time. The -d clipboard log would help (I had typed that wrong previously).

The current limit is set to 10, maybe that's too low:

--- src/xpra/client/gtk2/client.py	(revision 7831)
+++ src/xpra/client/gtk2/client.py	(working copy)
@@ -181,7 +181,7 @@
     def process_clipboard_packet(self, packet):
         clipboardlog("process_clipboard_packet(%s) level=%s", packet, gtk.main_level())
         #check for clipboard loops:
-        if gtk.main_level()>=10:
+        if gtk.main_level()>=25:
             clipboardlog.warn("loop nesting too deep: %s", gtk.main_level())
             clipboardlog.warn("you may have a clipboard forwarding loop, disabling the clipboard")
             self.clipboard_enabled = False

[totaam]

2014-10-06 07:29:10: jiang.qian commented

---

Great, I hope that'll help. I did a debugging session with -d clipboard flag. The outputs are in the two attached files. The setup is with eight gnome-terminal window open to trigger the bug.

Interestingly, in my experience, if the bug is triggered, e.g. with lots of gnome-terminal open, simply closing gnome-terminal windows doesn't help. Disconnect the session and reconnect and the bug is still there.

Only after logging out of the entire gui session and log back in on the client side would restore the normal copy and paste. Restarting xpra server is however not needed.

[totaam]

2014-10-06 07:29:55: jiang.qian uploaded file server-clipboard-debug-log.txt (60.8 KiB)

[totaam]

2014-10-06 07:30:09: jiang.qian uploaded file client-clipboard-debug-log.txt (76.0 KiB)

[totaam]

2014-10-06 15:11:56: totaam commented

---

OK, so it looks like all the terminals are requesting the clipboard contents at the same time, as soon as we claim ownership of it (which is lame - the point of the X11 clipboard is that you should only request it when you need it..).

I can't see an easy way around that: we have to use nesting to run the main loop until we get the results...

r7893 bumps the nesting level limit to 40, a loop will increase quickly anyway, so having a high limit is OK, better than hitting it too easily.

[totaam]

2014-10-27 19:17:48: totaam changed status from new to closed

[totaam]

2014-10-27 19:17:48: totaam changed resolution from ** to worksforme

[totaam]

2014-10-27 19:17:48: totaam commented

---

Not heard back, hopefully 40 is enough here.