Xpra: Ticket #1999: xterm regression: popup window does not get focus

Reported on the mailing list here: Xterm menus no mouse tracking.

Only occurs on parts of the popup window that overlap with the xterm window.

Tue, 23 Oct 2018 14:50:44 GMT - Antoine Martin:

Easy-ish to bisect:

The problem comes from r13690, which is a relatively small changeset, but one with big implications. The commit message links to #770, #1293, #911 and #469!

And indeed, using this env var "fixes" things:

XPRA_REPARENT_ROOT=0 xpra start ...

Let's try to find a workaround that doesn't require reverting this switch.

Tue, 30 Oct 2018 10:04:22 GMT - Antoine Martin:

Recording the window tree using sleep 5;DISPLAY=:15 xwininfo -root -tree;DISPLAY=:15 xdotool getactivewindow:

We only reparent the non-OR windows, but it's an OR window that's having this problem! No amount of trying to force the OR popup window on top of the xterm's main window makes any difference. Yet, it really does look like the motion events are delivered to the main window instead of the popup menu..

Tue, 30 Oct 2018 14:25:03 GMT - Antoine Martin: status changed

Got it, I think. Pointer events get reported against the parent (non-OR) window, which means that we raise it in _move_pointer. For some reason, that causes problems when the parent is not root - no idea why that is. Changing this code is tricky: this could cause all sorts of stacking / focus regressions. So maybe the easiest short term fix for 2.4 would be to selectively reparent to root (ie: not for Java windows so drag-n-drop will continue to work)

Wed, 31 Oct 2018 13:19:50 GMT - Antoine Martin:

_move_pointer calls window-model.raise_window which calls raise_ on the corral window. This pygtk call delegates to gdk_window_raise, the docstring reads: Raises @window to the top of the Z-order (stacking order), so that other windows with the same parent window appear below @window. This is true whether or not the windows are visible.

Deep breath.

Managing stacking is not easy, see Braindump: How to get window stacking right - a great read.

So, simply taking out the calls to raise_window "fixes" the problem, but we can't use this solution: we have no way of knowing what the window stacking is really like on the client side, and the client's window manager is free to re-arrange the window stacking at any point without telling us (we only get notified for big events like iconification, focus lost or gained - but not window stacking changes, especially on other platforms like win32 or macos). The call to raise_window ensures that the window which is meant to receive the pointer motion event really is the one on top, as there could be multiple overlapping windows at those exact coordinates.

The reason why "reparent to root" makes a difference is to do with how the window stack is searched for siblings during XRaiseWindow. When we don't "reparent to root", the search stops at the world window.

The solution adopted in r20890 is to keep track of the window we last raised and not raise it again. This works with override-redirect windows since the pointer events are still reported against the non-OR window. This may not work if pagers or the application themselves somehow re-arrange the stacking from underneath us.

r20892 tries to ensure that we do re-raise it again after events that may have pushed the window down the stack: new non-OR windows, focus events, raised_window requests.

Still TODO:

Tue, 13 Nov 2018 13:10:16 GMT - Antoine Martin: owner, status changed

The backport to v2.4 was in r20893 and this was included in version 2.4.1

@maxmylyn: I've never managed to reproduce the macos focus bug reliably, can you reproduce it with / without the workaround? If not then let's just close this ticket and leave it as-is.

Thu, 15 Nov 2018 17:29:34 GMT - J. Max Mena: status changed; resolution set

I tried this yesterday for a significant period of time and I cannot reproduce it at all. I suspect the fact that I'm using a Mac Mini that has a sub 2Ghz Intel CPU may be contributing negatively to my ability to reproduce this bug as even the Apple UI hangs periodically. I'm going to ahead and close this as "worksforme", but I suspect it may sneak back up on us in the future. I hope it doesn't, but you never know.

Thu, 15 Nov 2018 17:38:06 GMT - Antoine Martin:

@maxmylyn: is that with XPRA_OSX_FOCUS_WORKAROUND=0 or 1? With gtk2 or gtk3 builds?

Thu, 15 Nov 2018 18:15:06 GMT - J. Max Mena:

GTK2 build - with and without the debug flag enabled.

Fri, 16 Nov 2018 04:25:56 GMT - Antoine Martin:

r21007 changes the default to disabled. Hopefully GTK3 isn't affected by this bug.

Thu, 26 Dec 2019 07:47:32 GMT - Antoine Martin: status changed; resolution deleted

Regression spotted with trunk (4.0).

Mon, 30 Dec 2019 14:51:53 GMT - Antoine Martin: owner, status changed


Mon, 30 Dec 2019 16:54:12 GMT - Antoine Martin: status changed

Weirdest bug of the year nomination for this one. Applying this simple change on top of r23803 triggers the bug: changeset/23804/xpra/trunk/src/xpra/x11/models/model_stub.py.

Tested with:

python3 setup.py install --minimal --with-cython --with-x11 --with-server --with-gtk_x11 --with-gtk3 --with-modules --with-pillow

Trimming it further, here's the minimal change that triggers it:

--- xpra/x11/models/model_stub.py	(revision 23803)
+++ xpra/x11/models/model_stub.py	(working copy)
@@ -8,6 +8,7 @@
 from xpra.gtk_common.gobject_util import AutoPropGObjectMixin
 from xpra.gtk_common.gobject_compat import import_gobject
+from gi.repository import GObject as gobject
 from xpra.log import Logger
 gobject = import_gobject()

Mon, 30 Dec 2019 21:10:57 GMT - Antoine Martin:

And the bisection was wrong... That's because the bug doesn't always show up with the first popup click. Damn.

Re-bisecting, more carefully:

Problem is, this is a client side bug. So there may be another server side bug too.

Mon, 30 Dec 2019 21:21:13 GMT - Antoine Martin:

Client side bug fixed in r24842: the server does something undesirable if we send it focus-in events for OR windows.

Tue, 31 Dec 2019 10:23:39 GMT - Antoine Martin: status changed; resolution set

Glad I spent some time debugging the server end: r24845 is a better fix for both ends.

There used to be a workaround that returned the currently focused window instead (but only on macos): added in r8239, removed in r24845. This was related to #469. See also #770 / #1293 / #911.

Sat, 23 Jan 2021 05:39:25 GMT - migration script:

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