Xpra: Ticket #1642: xpra-controlled windows won't give up focus

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.



Fri, 15 Sep 2017 16:03:55 GMT - Antoine Martin: owner changed

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.


Wed, 25 Oct 2017 10:35:11 GMT - Antoine Martin: status changed; resolution set

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


Tue, 13 Aug 2019 21:11:27 GMT - Thomas Esposito: priority, status, version, milestone changed; resolution deleted

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.


Tue, 13 Aug 2019 21:11:41 GMT - Thomas Esposito: component changed


Wed, 14 Aug 2019 05:34:19 GMT - Antoine Martin: owner, status changed

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)


Thu, 15 Aug 2019 22:04:41 GMT - Thomas Esposito: attachment set


Thu, 15 Aug 2019 22:10:39 GMT - 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.


Thu, 15 Aug 2019 22:13:56 GMT - 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?


Fri, 16 Aug 2019 00:58:08 GMT - 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.


Tue, 20 Aug 2019 09:13:49 GMT - 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.


Tue, 20 Aug 2019 11:18:45 GMT - Thomas Esposito:

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


Sun, 25 Aug 2019 03:14:08 GMT - 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.


Tue, 27 Aug 2019 16:23:23 GMT - Thomas Esposito: attachment set

log with focus,grab,metadata debug info


Tue, 27 Aug 2019 16:26:08 GMT - Thomas Esposito: attachment set

dump of xpra info after problem has occurred


Tue, 27 Aug 2019 16:35:43 GMT - 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.


Tue, 27 Aug 2019 16:39:56 GMT - Thomas Esposito: attachment set

more weird behavior


Tue, 27 Aug 2019 16:41:25 GMT - Thomas Esposito: attachment set

dump of xpra info after 2nd problem has occurred


Tue, 27 Aug 2019 16:46:20 GMT - 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.


Tue, 27 Aug 2019 16:48:28 GMT - Thomas Esposito:

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


Wed, 28 Aug 2019 05:12:49 GMT - 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.


Tue, 17 Sep 2019 17:13:01 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:29:53 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1642