xpra icon
Bug tracker and wiki

Opened 2 years ago

Last modified 3 weeks ago

#1642 new defect

xpra-controlled windows won't give up focus

Reported by: Thomas Esposito Owned by: Thomas Esposito
Priority: minor Milestone: 3.0
Component: client Version: 1.0.x
Keywords: Cc:

Description

I am running the Xpra 2.1 client on Windows 10.

Sometimes, after I have clicked on the taskbar icon in order to bring another application window into focus (either a native Windows application or another xpra X application window), the current xpra X application remains on top and retains focus. The only way I can get to my other application is to minimize the offending xpra X application window. The offending application seems to be gnome-terminal more often than not.

I'm not sure if this a client or server issue, but for what it's worth, I'm running xpra server version 1.0.6 on RHEL6.6.

Attachments (5)

xpra_window_focus_log.txt (6.8 KB) - added by Thomas Esposito 5 weeks ago.
filtered_xpra.log (11.5 KB) - added by Thomas Esposito 3 weeks ago.
log with focus,grab,metadata debug info
xpra.info (170.5 KB) - added by Thomas Esposito 3 weeks ago.
dump of xpra info after problem has occurred
filtered_xpra2.log (7.3 KB) - added by Thomas Esposito 3 weeks ago.
more weird behavior
xpra.info2 (169.5 KB) - added by Thomas Esposito 3 weeks ago.
dump of xpra info after 2nd problem has occurred

Download all attachments as: .zip

Change History (20)

comment:1 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to Thomas Esposito

Please try to narrow it down by running a different client OS (ie: Linux).
When the problem occurs, try to capture the client output with the debug flag "-d focus", or maybe even "-d focus,win32".
Having minimal reproducible steps would help me fix this.

comment:2 Changed 23 months ago by Antoine Martin

Resolution: needinfo
Status: newclosed

Not heard back, closing. Feel free to re-open with more details.

comment:3 Changed 5 weeks ago by Thomas Esposito

Milestone: 2.23.0
Priority: majorminor
Resolution: needinfo
Status: closedreopened
Version: 2.1.x1.0.x

I've been living with this for quite a while and decided to give it another go. Can you give instructions on how to capture focus debug info when running the Windows client? I tried starting the the client with "Xpra-Launcher.exe -d focus,win32", but I don't see any log messages in the command prompt window, nor do I see any log files being written.

I don't have access to a Linux client.

comment:4 Changed 5 weeks ago by Thomas Esposito

Component: androidclient

comment:5 Changed 5 weeks ago by Antoine Martin

Owner: changed from Thomas Esposito to Thomas Esposito
Status: reopenednew

but I don't see any log messages in the command prompt window, nor do I see any log files being written.

I'm not sure if using the launcher will honour the -d flags.
The log files go in %APPDATA% on win32.

The easiest way would be to launch xpra like this:

xpra_cmd attach -d win32,focus tcp://host:port

(or ssh or whatever)

Changed 5 weeks ago by Thomas Esposito

Attachment: xpra_window_focus_log.txt added

comment:6 Changed 5 weeks ago by Thomas Esposito

Just to clarify the issue, other windows can get focus, but they CANNOT draw over the problem window. Currently, in my client, I have a gnome-terminal and an xemacs window overlapping each other. The gnome-terminal window is ALWAYS drawn on top, even if the xemacs window has focus. In fact, no other windows, xpra or non-xpra, can be drawn over the gnome-terminal window.

So the original description regarding focus is not quite correct. This is more about drawing than focus.

Anyway, at the beginning of the attached log file, the xemacs window has focus, but is being incorrectly drawn underneath the gnome-terminal window. Then, I click on the gnome-terminal title bar, then the xemacs title bar, then gnome-terminal again, than xemacs again. Each time, the focus changes to the appropriate window, but gnome-terminal window is ALWAYS drawn on top regardless of focus.

comment:7 Changed 5 weeks ago by Thomas Esposito

It just occurred to me that the attached log file may be useless because it only has focus info, which doesn't seem to be the real problem. Knowing now that the real problem is drawing/clipping, are there other debug flags that I should be using?

comment:8 Changed 5 weeks ago by Antoine Martin

It just occurred to me that the attached log file may be useless because it only has focus info, which doesn't seem to be the real problem. Knowing now that the real problem is drawing/clipping, are there other debug flags that I should be using?

Try -d focus,grab,metadata.
It's either a grab issue, or the window metadata is telling us to keep it on top.

comment:9 Changed 4 weeks ago by Vincent Huisman

I think it's the same problem as #713, or at least the same symptoms. The "fix" from there (right-click tray icon and Windows -> Raise Windows) works for me, too. Very annoying that it happens every now and then, unfortunately I haven't been able to properly reproduce it, it just happens a couple of times a day. I've observed it on two different machines and across Xpra versions, although they're both running Windows 10. Currently I'm using Xpra 2.5.2-r22874 x64 as client, and Xpra 2.5.3-r23270 on Kubuntu 19.04 as server. OpenGL is enabled on my desktop machine (AMD Radeon RX 5700 XT) and also on my laptop (NVIDIA Quadro 2000M). I'll try to keep some logs running.

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

comment:10 Changed 4 weeks ago by Thomas Esposito

I'm still waiting for it to happen again...

comment:11 Changed 3 weeks ago by Antoine Martin

There were quite a few important focus related fixes recently: #2390, though those affected client-to-server synchronization.

It would really help to have xpra info captured when the problem occurs.
Then we can see if the window has the "stay-on-top" flag set or something.

Changed 3 weeks ago by Thomas Esposito

Attachment: filtered_xpra.log added

log with focus,grab,metadata debug info

Changed 3 weeks ago by Thomas Esposito

Attachment: xpra.info added

dump of xpra info after problem has occurred

comment:12 Changed 3 weeks ago by Thomas Esposito

Just uploaded new logs. I'll attempt to describe the state of things when this happened:

I have 3 monitors. On my 3rd monitors, I had the following windows in view:

1.) A non-maximized xpra xemacs window on top near the middle of the screen.
2.) A non-maximized xpra gnome-teriminal window partially obscured by the lower-right part of the xemacs window.
3.) A non-maximized native Window 10 application window partially obscured by the upper-left part of the xemacs window.
4.) Another maximized xpra application window below all of the others on the same screen.

The filtered_xpra.log is for the following sequence:
1.) Click on the xeamcs window. It remains on top and gets focus of course.
2.) Click on native Windows 10 application window. It gains focus but remains partially obscured by the xemacs window.
3.) Click on the gnome-terminal window. It gains focus but remains partially obscured by the xemacs window.
4.) Clock on the xemacs window again and it gains focus. Still on top.

Changed 3 weeks ago by Thomas Esposito

Attachment: filtered_xpra2.log added

more weird behavior

Changed 3 weeks ago by Thomas Esposito

Attachment: xpra.info2 added

dump of xpra info after 2nd problem has occurred

comment:13 Changed 3 weeks ago by Thomas Esposito

Right after I posted the last update, I observed some more interesting behavior. The associated files are filtered_xpra2.log and xpra.info2.

State prior to filtered_xpra2.log activity:

Maximized xpra application window (wid=569) has focus, but is still partially obscured by xemacs (wid=2) and gnome-terminal (wid=1) windows, which are overlapping.

Sequence captured in filtered_xpra2.log:

1.) Click title bar of wid=569 (the maximized window). It keeps focus but DOES NOT rise to top (i.e. still obscured by both wid=2 and wid=1).

2.) Click title bar of wid=2. Gains focus and rises to top over both wid=569 and wid=1.

3.) Click title bar of wid=1. Gains focus and rises to top over both wid=569 and wid=2.

4.) Click title bar of wid=569 (i.e. the maximized one). It gains focus but remains obscured by both wid=1 and wid=2.

Last edited 3 weeks ago by Thomas Esposito (previous) (diff)

comment:14 Changed 3 weeks ago by Thomas Esposito

"Raise Windows" appears to resolve the issue (at least temporarily).

comment:15 Changed 3 weeks ago by Antoine Martin

From xpra info:

server.build.version=1.0.13
server.platform.linux_distribution=('RedHatEnterpriseServer', '6.6', 'Santiago')

But:

client.version=2.1.2

Really??
Try a supported version, or even the latest beta builds with the focus fixes.
Anything that old is bound to have lots of problems.
Otherwise, I will close as 'invalid'.

My only hunch is that this may be related to the hooks we inject.
You could try running the client with:

CLIP_CURSOR=0 xpra_cmd attach ...

Or even WINDOW_HOOKS=0 to disable them all. But I'm not sure what effect this has on an outdated version.

Note: See TracTickets for help on using tickets.