Xpra: Ticket #282: focus problems with CentOS5.x

(split from #266) Up-to-date CentOS 5.9 with latest xpra 0.8.8 has focus problems:

xpra start :10 --start-child=xterm

Connecting from a working system (any, ie: Fedora 18) and the xterm refuses to take focus, though the focus events are being processed:

2013-03-07 07:06:27,084 will process ui packet focus
2013-03-07 07:06:27,086 _focus(4,('mod2',)) has_focus=0
2013-03-07 07:06:27,087 Giving focus to client

I am pretty sure this is this a regression since I had tested CentOS 5.x (at least for v0.8.0?) Contrary to what is stated in #266, this is not related to using dbus-launch.

Thu, 07 Mar 2013 16:28:01 GMT - Antoine Martin:

Well, that's a major PITA:

Thu, 07 Mar 2013 17:36:37 GMT - Antoine Martin: status changed

Bisecting was not fun (many patches to apply each time), but I've found a revision that did work... and it's a buggy one, the fix that breaks CentOS 5.x is a valid fix: r2003 Reverting it is not an option.

Setting "WMHints.input" causes WindowModel to set "_input_field" in _handle_wm_hints and also fires a "can-focus" notification. It also makes do_get_property_can_focus return a value. And it makes give_client_focus use XSetInputFocus...

Thu, 07 Mar 2013 18:30:16 GMT - Antoine Martin:

With this patch:

--- src/wimpiggy/prop.py	(revision 2907)
+++ src/wimpiggy/prop.py	(working copy)
@@ -113,6 +113,7 @@
             self.start_iconic = (initial_state == const["IconicState"])
             self.start_iconic = None
+        log.info("WMHints.InputHint=%s, _input=%s", flags & const["InputHint"], _input)
         if flags & const["InputHint"]:
             self.input = _input

and an xterm as client, on a system that works, I get one message:

WMHints.InputHint=1, _input=1

But on CentOS 5.x, I get:

WMHints.InputHint=1, _input=1
WMHints.InputHint=1, _input=0

The second one is 6ms after the first, it clears the input flag and we honour it... Why is it set and then unset?? (also happens with gedit as client app, and probably many more..)

Are we causing it to be unset somehow? Are we meant to ignore the second value? (can't think of why) Maybe knock up a simple gtk test app, then an X11 one.. Surely this property change comes from the application itself. (maybe look at the xterm source code..)

Fri, 08 Mar 2013 04:48:51 GMT - Antoine Martin: attachment set

very simple X11 test application which sets the input=True hint only once

Fri, 08 Mar 2013 06:31:44 GMT - Antoine Martin: status changed; resolution set

With the simple application attached, I still get the set/unset log messages... Looks like the window does lose its WMHints as we reparent it. Maybe an X11 server bug?

I've looked at the source code for sawfish and fvwm (setup_wm_hints) and both only set the input mode after reading the wmhints when they capture the window, it does not seem possible to change the input attribute afterwards.

So r2910 does something similar: we only set the input_field once (whenever the application sets the InputHint mask on wmhints), and we don't allow this value to change thereafter. I don't like this since the spec does not say anything about restricting the number of times one can call XSetWMHints or why we should discard certain attributes. But back in the real world, it looks like we need this, and I can't imagine why an application would want to change this value through the lifetime of a window.

Sat, 23 Jan 2021 04:50:29 GMT - migration script:

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