xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 2 months ago

#2715 closed defect (needinfo)

Issues with clicks on Tray menu and in Eclipse

Reported by: jonathan Owned by: jonathan
Priority: major Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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.

Attachments (1)

:9677.log (102.1 KB) - added by jonathan 3 months ago.
Log with -d clipboard,tray

Download all attachments as: .zip

Change History (20)

comment:1 Changed 3 months ago by jonathan

Component: androidclient

comment:2 Changed 3 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to jonathan

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 #2359: start xpra with --input-method=ibus then run ibus-daemon --xim -v in the session

comment:3 in reply to:  2 Changed 3 months ago by jonathan

Owner: changed from jonathan to Antoine Martin

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 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 #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?

comment:4 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan

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.

Changed 3 months ago by jonathan

Attachment: :9677.log added

Log with -d clipboard,tray

comment:5 in reply to:  4 Changed 3 months ago by jonathan

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!

comment:6 Changed 3 months ago by Antoine Martin

I think that the key here is this:

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

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.

Version 0, edited 3 months ago by Antoine Martin (next)

comment:7 Changed 3 months ago by 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.
I do see crappy repaint behaviour from eclipse... not sure there's much we can do about that though.

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:8 in reply to:  7 Changed 3 months ago by jonathan

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.

comment:9 Changed 3 months ago by 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)

comment:10 in reply to:  9 Changed 3 months ago by jonathan

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 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.

comment:11 in reply to:  6 Changed 3 months ago by jonathan

Replying to 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!

Last edited 3 months ago by jonathan (previous) (diff)

comment:12 Changed 3 months ago by Antoine Martin

Owner: changed from jonathan to Antoine Martin
Status: newassigned

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

comment:13 in reply to:  12 Changed 3 months ago by jonathan

Replying to Antoine Martin:

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

Great!

comment:14 Changed 3 months ago by jonathan

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.

comment:15 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan
Status: assignednew

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.

comment:16 Changed 3 months ago by jonathan

Owner: changed from jonathan to Antoine Martin

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.

comment:17 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan

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'.

comment:18 Changed 3 months ago by jonathan

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.

comment:19 Changed 2 months ago by Antoine Martin

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