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.
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:
Discovered new override-redirect window: 0xa0290bL (tray=None)
new_window(new-override-redirect, \
<OverrideRedirectWindowModel object at 0x25132d0 (xpra+x11+gtk_x11+window+OverrideRedirectWindowModel at 0x7f7f34017ba0)>, \
14, 1885, 302, 455, 174, None) \
metadata={
'fullscreen': False, 'window-type': ['COMBO', 'NORMAL'], 'xid': '0xa0290b', \
'maximized': False, 'transient-for': 13, 'override-redirect': True, 'has-alpha': False
}
<class 'xpra.client.gtk2.client_window.ClientWindow'>(<XpraClient object at 0x25cd5f0 (xpra+client+gtk2+client+XpraClient at 0x1dd4ac0)>, \
None, \
14, 1885, 302, 455, 174, \
{
'fullscreen': False, 'has-alpha': False, 'xid': '0xa0290b', \
'window-type': ('COMBO', 'NORMAL'), 'maximized': False, \
'transient-for': 13, \
'override-redirect': True}, \
True, {}, 0)
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)>
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.
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
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.
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)
r3708 removes "modal" window support from gtk2
We'll need to check that this doesn't cause any regressions with modal windows and focus..
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.
Note: the fix in #336 has been reverted - keeping this open.
Re-scheduling, focus and grabs will be a priority for 0.11
re-scheduling (again)
Looks like #139, which is fixed. I don't want/care/have ensight, so closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/356