xpra icon
Bug tracker and wiki

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#282 closed defect (fixed)

focus problems with CentOS5.x

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 0.9
Component: core Version: 0.8.x
Keywords: Cc:

Description

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

Attachments (1)

little-x-example.c (2.4 KB) - added by Antoine Martin 7 years ago.
very simple X11 test application which sets the input=True hint only once

Download all attachments as: .zip

Change History (5)

comment:1 Changed 7 years ago by Antoine Martin

Well, that's a major PITA:

  • trunk obviously works fine on all other platforms
  • adding debugging to show any exceptions in the trap.swallow wrapping around the "give_client_focus" code does not reveal anything
  • trying to bisect things is very difficult as anything older than a few hundred revisions back requires multiple patches to run, and further back gets more and more difficult..

comment:2 Changed 7 years ago by Antoine Martin

Status: newassigned

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

comment:3 Changed 7 years ago by 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"])
         else:
             self.start_iconic = None
+        log.info("WMHints.InputHint=%s, _input=%s", flags & const["InputHint"], _input)
         if flags & const["InputHint"]:
             self.input = _input
         else:

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

Changed 7 years ago by Antoine Martin

Attachment: little-x-example.c added

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

comment:4 Changed 7 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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.

Last edited 7 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.