xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

#356 closed defect (fixed)

ensight with win32 client has drop down focus problems

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 0.12
Component: client Version:
Keywords: win32 Cc:

Description (last modified by 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.

Change History (12)

comment:1 Changed 6 years ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 6 years ago by 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)>
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 6 years ago by 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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 years ago by 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

comment:5 Changed 6 years ago by 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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 6 years ago by 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)

comment:7 Changed 6 years ago by 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..

comment:8 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by Antoine Martin

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

comment:10 Changed 6 years ago by Antoine Martin

Milestone: 0.100.11
Owner: changed from Antoine Martin to Antoine Martin
Status: assignednew

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

comment:11 Changed 6 years ago by Antoine Martin

Milestone: 0.110.12
Status: newassigned

re-scheduling (again)

comment:12 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.