Hi,
This issue was created as a spinoff from #2713.
I upgraded to xpra 3.0.8-r25889 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 ticket: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.
Just like #2713, I assume:
OpenGL enabled with Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)
Questions:
python2 /usr/bin/xpra
instead of the default python3
?
opengl
, clipboard
in the client?
--input-method=ibus
then run ibus-daemon --xim -v
in the session
Replying to 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 defaultpython3
?
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 #2359: start xpra with
--input-method=ibus
then runibus-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?
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.
Log with -d clipboard,tray
Replying to 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!
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:
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.
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.
Replying to 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.
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
)
Replying to 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
orrgb
)
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.
Replying to Antoine Martin:
Can you try:
XPRA_DISCARD_TARGETS=^resource-transfer-format xpra startthen
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!
Applied in r26045. I will try to find a better fix for eclipse since this is reproducible.
Replying to Antoine Martin:
Applied in r26045. I will try to find a better fix for eclipse since this is reproducible.
Great!
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.
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.
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.
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'.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2715