Issues with clicks on Tray menu and in Eclipse

[totaam]

Issue migrated from trac ticket # 2715

component: client | priority: major | resolution: needinfo

2020-04-07 11:11:15: jonathan created the issue

---

Hi,

This issue was created as a spinoff from #2713.

I upgraded to xpra 3.0.8-25889 from 2.1.3 on Ubuntu 18.04 with i3-gnome, and the system tray icon disappeared. Antoine Martin helped fix so that the tray icon reappeared. But I have to click and hold to be able to manipulate it. Before the upgrade I could just click and the menu would stay open until i selected something or pressed Esc.

I also noticed that there are issues using clicks in Eclipse, running on a Debian server with the same version of xpra. Before the upgrade clicks worked (see #2713 for more details on the upgrade). At first clicks in Eclipse work, but then there are issues. Double click to open files in the file panel does not work. To right click I have to press and hold to see the menu, that appears after a little while. When the clicks fail I see a clipboard icon on the Xpra tray menu. Launching xpra with XPRA_CLIPBOARD_NOTIFY=0 xpra attach ... as suggested in comment #2713#comment:21 does not help. Another suggestion in the same comment refers to ibus issues, but I do not have ibus installed. Clicks so far seem to work fine in p4v that is running in the same xpra session.

I get warnings from xpra on the client:

2020-04-07 11:57:23,600 Warning: CLIPBOARD selection request for 'resource-transfer-format:1586182768802:944468364' timed out
2020-04-07 11:57:23,601  request 0 at time=0
2020-04-07 11:57:24,121 Warning: CLIPBOARD selection request for 'resource-transfer-format:1586182768802:944468364' timed out
2020-04-07 11:57:24,121  request 1 at time=0
2020-04-07 11:57:24,886 Warning: CLIPBOARD selection request for 'resource-transfer-format:1586182768802:944468364' timed out
2020-04-07 11:57:24,886  request 2 at time=0

Something is interpreting normal clicks as clipboard requests.

This regression was triggered by something that changed between xpra version 2.1.3 that is default on Ubuntu 18.04 and version 3.0.8.

[totaam]

2020-04-07 11:14:25: jonathan changed component from android to client

[totaam]

2020-04-07 11:26:46: antoine changed owner from antoine to jonathan

[totaam]

2020-04-07 11:26:46: antoine edited the issue description

[totaam]

2020-04-07 11:26:46: antoine commented

---

Just like #2713, I assume:

• window manager is 'i3'
• connection via ssh
• OpenGL enabled with Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)

Questions:

• does the problem go away if you start your server with python2 /usr/bin/xpra instead of the default python3?
• same with the client (switch to python2)
• have you tried disabling opengl, clipboard in the client?
• maybe try the ibus workaround from switch input method to ibus? #2359: start xpra with --input-method=ibus then run ibus-daemon --xim -v in the session

[totaam]

2020-04-07 12:11:33: jonathan changed owner from jonathan to Antoine Martin

[totaam]

2020-04-07 12:11:33: jonathan commented

---

Replying to [comment:2 Antoine Martin]:

Just like #2713, I assume:

• window manager is 'i3'
• connection via ssh
• OpenGL enabled with Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)

You assume correctly.

Questions:

• does the problem go away if you start your server with python2 /usr/bin/xpra instead of the default python3?
  Would need to install the python2 version of xpra then. Not tested yet. The server is shared so I need to be careful when installing things.
• same with the client (switch to python2)
  Tested, no change.
• have you tried disabling opengl, clipboard in the client?
  Disabling clipboard made right and left click in Eclipse work. You still have to long press when using the Xpra tray menu.
  Disabling opengl made no change.
• maybe try the ibus workaround from switch input method to ibus? #2359: start xpra with --input-method=ibus then run ibus-daemon --xim -v in the session
  Ibus is not installed on my client computer.

So it appears something in the clipboard handling is not functioning as intended. Can I activate some type of logging to get more info to you?

[totaam]

2020-04-07 13:11:45: antoine changed owner from Antoine Martin to jonathan

[totaam]

2020-04-07 13:11:45: antoine commented

---

You still have to long press when using the Xpra tray menu.
-d tray might give us a clue.

Ibus is not installed on my client computer.
This would be for the server.

So it appears something in the clipboard handling is not functioning as intended. Can I activate some type of logging to get more info to you?
Yes: -d clipboard, use this switch on both client and server then post the server log.

[totaam]

2020-04-07 13:55:09: jonathan uploaded file :9677.log (102.1 KiB)

Log with -d clipboard,tray

[totaam]

2020-04-07 13:55:47: jonathan commented

---

Replying to [comment:4 Antoine Martin]:

Ran with -d clipboard,tray on both server and client. Attaching server log (server and user name replaced). Did click on the tray icon first, then launched eclipse and clicked on files in the file panel a couple of times. Hope this helps you!

[totaam]

2020-04-07 15:11:36: antoine commented

---

I think that the key here is this:

client   1 @12.072 requesting local XConvertSelection from 'Firefox' as 'resource-transfer-format:1586263330424:778520216' into 'CLIPBOARD-resource-transfer-format:1586263330424:778520216'
client   1 @19.304 Warning: CLIPBOARD selection request for 'resource-transfer-format:1586263330424:778520216' timed out
client   1 @19.305  request 7 at time=0

It's requesting the strange resource-transfer-format:1586263330424:778520216 format from Firefox.

Found some links:

• org/eclipse/ui/part/ResourceTransfer.java
• Clipboard: Eclipse workbench hangs when switching to from rdesktop session

---

Can you try:

XPRA_DISCARD_TARGETS=^resource-transfer-format xpra start

then

XPRA_DISCARD_TARGETS=^resource-transfer-format xpra attach ...

It's wrong for eclipse to wait for the clipboard data to show its menu - that's not how the X11 clipboard is meant to be used.
Anyway, this workaround will still be clunky on a slow link, but at least it won't have to timeout.

[totaam]

2020-04-07 15:37:54: antoine commented

---

FWIW: I've just tried to reproduce the problem and I can't hit it.
That's using "eclipse from snap" on Ubuntu 18.04.
I do see crappy repaint behaviour from eclipse... not sure there's much we can do about that though.

[totaam]

2020-04-08 08:25:51: jonathan commented

---

Replying to [comment:7 Antoine Martin]:

FWIW: I've just tried to reproduce the problem and I can't hit it.
That's using "eclipse from snap" on Ubuntu 18.04.
We use this one:
https://www.eclipse.org/downloads/packages/release/2018-09/r/eclipse-ide-cc-developers

I do see crappy repaint behaviour from eclipse... not sure there's much we can do about that though.
I was going to ask about that. Before the upgrade from older xpra I did not notice this, there were other issues with the video that probably masked it. I read something in another trac about you doing something special when scrolling, comparing pixels? Is it possible to do something like that now? We're also evaluating FastX, and there are no such issues when using that. The line numbers lag when scrolling, similar to what you get with X over ssh.

[totaam]

2020-04-08 08:34:32: antoine commented

---

I read something in another trac about you doing something special when scrolling, comparing pixels?
Is it possible to do something like that now?
Scrolling has been enabled for over 3 years: #1232, now even without opengl #2295 (in v2.5.x) or requiring video detection (#2248)

Use -d compress on the server to see how pixels are being sent (in your case: scrolling or rgb)

[totaam]

2020-04-08 14:32:51: jonathan commented

---

Replying to [comment:9 Antoine Martin]:

I read something in another trac about you doing something special when scrolling, comparing pixels?
Is it possible to do something like that now?
Scrolling has been enabled for over 3 years: #1232, now even without opengl #2295 (in v2.5.x) or requiring video detection (#2248)

Use -d compress on the server to see how pixels are being sent (in your case: scrolling or rgb)
It's a mix of different formats when in auto mode. When I try to select one format smaller areas are sometimes not sent as the selected format, but I guess that is expected.

[totaam]

2020-04-08 14:40:55: jonathan commented

---

Replying to [comment:6 Antoine Martin]:

Can you try:

XPRA_DISCARD_TARGETS=^resource-transfer-format xpra start

then

XPRA_DISCARD_TARGETS=^resource-transfer-format xpra attach ...

It's wrong for eclipse to wait for the clipboard data to show its menu - that's not how the X11 clipboard is meant to be used.
Anyway, this workaround will still be clunky on a slow link, but at least it won't have to timeout.

Now it is possible to click, and normal copy paste works. Thank you!

[totaam]

2020-04-08 14:45:18: antoine changed status from new to assigned

[totaam]

2020-04-08 14:45:18: antoine changed owner from jonathan to antoine

[totaam]

2020-04-08 14:45:18: antoine commented

---

Applied in r26045. I will try to find a better fix for eclipse since this is reproducible.

[totaam]

2020-04-08 15:00:13: jonathan commented

---

Replying to [comment:12 Antoine Martin]:

Applied in r26045. I will try to find a better fix for eclipse since this is reproducible.
Great!

[totaam]

2020-04-08 15:03:04: jonathan commented

---

Regarding the flickering I'm trying this:
https://stackoverflow.com/questions/41147840/eclipse-flickering-on-new-line
Will see if it improves. The menu bars etc are uglier though :-).

Apparently there are also issues when you are not using ibus:
https://subhadipsblog.wordpress.com/2019/01/25/how-to-fix-eclipse-ide-flickering-issue-on-debian/
None of the client and server have ibus installed.

[totaam]

2020-04-08 18:08:18: antoine changed status from assigned to new

[totaam]

2020-04-08 18:08:18: antoine changed owner from antoine to jonathan

[totaam]

2020-04-08 18:08:18: antoine commented

---

I will try to find a better fix for eclipse since this is reproducible.
I really cannot reproduce your problem, even after downloading the same version of eclipse (from comment:8) and copying to and from Firefox.

What am I doing wrong?

---

As for the flickering, this is not an xpra bug, eclipse just uses a very inefficient and ugly way to repaint windows and this is exacerbated when displayed remotely via xpra.

[totaam]

2020-04-09 09:23:54: jonathan changed owner from jonathan to Antoine Martin

[totaam]

2020-04-09 09:23:54: jonathan commented

---

I don't know what Firefox came from in the logs. The issues are only related to clicking (left and right). I read the trac description again and it is still valid. Perhaps the last thing in the clipboard was from Firefox when I clicked on files in the file panel? Copy and paste always work, it's only clicking that has issues, such as opening files with the mouse not working.

[totaam]

2020-04-09 11:05:46: antoine changed owner from Antoine Martin to jonathan

[totaam]

2020-04-09 11:05:46: antoine commented

---

I don't know what Firefox came from in the logs.
From your log: requesting local XConvertSelection from 'Firefox' as 'resource-transfer-format:1586263330424:778520216' into 'CLIPBOARD-resource-transfer-format:1586263330424:778520216' means that Firefox owns the CLIPBOARD selection and Eclipse is asking for it.

The issues are only related to clicking (left and right).
When you click, Eclipse may request the clipboard contents or targets (ie: to decide if the "copy" and "paste" menu items should be enabled), which is why you were seeing problems when those requests were timing out.

I read the trac description again and it is still valid.
I am unable to reproduce it no matter how hard I try: I do see events when I click, but I never see the resource-transfer-format token.

Perhaps the last thing in the clipboard was from Firefox when I clicked on files in the file panel?
Yes.

Copy and paste always work, it's only clicking that has issues, such as opening files with the mouse not working.
Eclipse can trigger clipboard copy events when clicking - which is why disabling the clipboard or applying the patch (or environment variable) fixes things.

Can you please try from a clean installation, like I just did.
If I cannot reproduce the bug, I will have to close as 'needinfo'.

[totaam]

2020-04-17 06:14:47: jonathan commented

---

Ok thank you. I've not had time to look in to this this week. We have a couple of plugins attached, maybe that has to do with it. Not sure if I will have time next week as well, but the week after I can test will a clean Eclipse.

[totaam]

2020-05-08 15:18:26: antoine changed status from new to closed

[totaam]

2020-05-08 15:18:26: antoine set resolution to needinfo