Xpra: Ticket #356: ensight with win32 client has drop down focus problems

Running EnSight Free (proprietary with a "free" version)

This affects all versions, including trunk. This only affects the win32 client (not tested OSX) but not the Linux clients.



Fri, 21 Jun 2013 05:31:29 GMT - Antoine Martin: status, description changed


Fri, 21 Jun 2013 06:39:27 GMT - Antoine Martin:

Here's the information on the dialog window that shows up when one clicks on "File -> Open" (captured client-side):

<class 'xpra.client.gtk2.client_window.ClientWindow'>(<XpraClient object at 0x25cd5f0 (xpra+client+gtk2+client+XpraClient at 0x1dd4ac0)>, \
    <gtk.gdk.Window object at 0x7f5f70007a50 (GdkWindow at 0x2166480)>, \
    13, 0, 0, 642, 500, \
    {
    'size-constraints': {'minimum-size': (642, 410)}, \
    'fullscreen': False, 'has-alpha': False, 'xid': '0xa0230a', \
    'title': 'Open...', 'client-machine': 'desktop', 'pid': 10795, \
    'window-type': ('DIALOG', 'NORMAL'), 'modal': True, 'maximized': False, \
    'transient-for': 2, 'class-instance': ('ensight10.client', 'Ensight10.client')\
    }, \
    False, {}, 0)

And this is the "window" that contains the drop down menu:

When we click on the drop down menu with the Linux client, we see (server side):

will process ui packet pointer-position
(...)
will process ui packet button-action
will process ui packet button-action
world window got focus
do_unmanaged(False) damage_forward_handle=254, \
     composite=<CompositeHelper object at 0x2513370 (xpra+x11+gtk_x11+composite+CompositeHelper at 0x1ba1280)>

Fri, 21 Jun 2013 08:18:19 GMT - Antoine Martin:

Found another related bug, which affects Linux clients too this time: the dialog window is modal ('window-type': ('DIALOG', 'NORMAL')) and so we block input to all the other windows until it is dismissed - including our own windows like "session-info". The reason why the drop down remains above all other windows on win32 is because there are no "group leaders" on win32, so when we set a window to be "above others" we cannot specify which other windows it is above of and it ends up being above all of them.. But on Linux, the "group-leader" stuff should work and we should still be able to interact with the other windows.

Maybe we can drop 'DIALOG' and see what happens?


Next strange thing: when processing clicks from a Linux client, I see for each click:

will process ui packet button-action
will process ui packet button-action

That's 2 events: one for press and one for release.

But with a win32 client only one:

will process ui packet button-action

Adding a bit of debug in mouse events, I see:

_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=194.00, y=70.00, button=1>, False) \
    pointer=(281, 170), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F518: GDK_BUTTON_RELEASE x=194.00, y=58.00, button=1>, False) \
    pointer=(281, 158), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=196.00, y=47.00, button=1>, False) \
    pointer=(283, 147), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=196.00, y=78.00, button=1>, False) \
    pointer=(283, 178), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=193.00, y=116.00, button=1>, False) \
    pointer=(280, 216), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=192.00, y=140.00, button=1>, False) \
    pointer=(279, 240), modifiers=['mod2'], buttons=[1]
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=192.00, y=153.00, button=1>, False) \
    pointer=(279, 253), modifiers=['mod2'], buttons=[1]

So on win32 we get a button release, but never the button press... which gets the server all confused: it rightfully ignores the button release since we never told it where/when we did the button press.


Fri, 21 Jun 2013 09:10:51 GMT - Antoine Martin:

r3672 fixes the drop down menus with ensight on win32

I will backport to v0.9.x then either fix the "group-leader" / "window stays on top of other window problem" (at the very least on Linux where this should be solvable) as detailed in comment:3


Sun, 23 Jun 2013 12:00:05 GMT - Antoine Martin:

The group-leader stuff is non-trivial, we now have improvements:

But we still have window focus problems... we can focus away from the modal window, but somehow it regains focus on the next event.


Sun, 23 Jun 2013 15:25:34 GMT - Antoine Martin:

I am afraid that the fix for modal windows stealing the input focus is very hard indeed, this mozilla bug from 2001 shows that this is a gtk limitation: it blocks input events to all the windows when a modal window is shown.


Their fix keeps track of which windows can receive events and only steals those events for the modal window when the parents of a modal window receive them, letting other windows get their events as expected. Our options:

Also somewhat related to: #336, #214


FWIW: Qt does things differently: WindowModality-enum supports NonModal, WindowModal (which is what we want) and ApplicationModal (which is what gtk does)


Sun, 23 Jun 2013 15:51:09 GMT - Antoine Martin:

r3708 removes "modal" window support from gtk2

We'll need to check that this doesn't cause any regressions with modal windows and focus..


Tue, 25 Jun 2013 04:33:08 GMT - Antoine Martin:

The popup menu sticking on top of windows when one switches away from it has been dealt with in #336: we don't do input grabs, we just manually manage OR windows losing focus server-side.


Thu, 11 Jul 2013 16:39:21 GMT - Antoine Martin:

Note: the fix in #336 has been reverted - keeping this open.


Sat, 10 Aug 2013 05:37:34 GMT - Antoine Martin: owner, status, milestone changed

Re-scheduling, focus and grabs will be a priority for 0.11


Thu, 17 Oct 2013 07:37:07 GMT - Antoine Martin: status, milestone changed

re-scheduling (again)


Tue, 04 Feb 2014 16:34:02 GMT - Antoine Martin: status changed; resolution set

Looks like #139, which is fixed. I don't want/care/have ensight, so closing.


Sat, 23 Jan 2021 04:52:37 GMT - migration script:

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