ensight with win32 client has drop down focus problems

[Antoine Martin]

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

• click on File -> Open
• try to interact with "File Type" (also affects the drop down menu found in "Format")

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

[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:

• server-side:

  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
      }
  

• client-side on Linux:

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

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

[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

[Antoine Martin]

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

• r3703 makes the server expose the client application's "group-leader" info (if it exists)
• r3705 uses this new "group-leader" info (and fallsback to using the pid as before)
• r3704 fixes when we set the group leader so it will be set correctly before the window is mapped (gtk2 only)

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

[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:

• do something similar
• re-use the gdk event loop code to deliver events ourselves
• if another, non-modal window receives the input focus.. only dirty hacks come to mind

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)

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

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

[Antoine Martin]

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

[Antoine Martin]

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

[Antoine Martin]

re-scheduling (again)

[Antoine Martin]

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

[migration script]

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