Jide Popup Always on Top

[totaam]

Issue migrated from trac ticket # 1955

component: server | priority: major | resolution: fixed

2018-09-10 19:16:21: mjharkin created the issue

---

In the attached example app the popup windows always stays on top.
However the expected behaviour (without Xpra) is that the window should behave like normal windows, i.e fall behind other windows.

The attached image expected.png shows the Main window is able to be dragged over the popup window outside Xpra and actual.png shows how in Xpra the popup window always stays on top when the main window is dragged over it.

To replicate:

Install Java and from extracted zip run java -jar testJidePop.jar.
Drag the main window over the popup window... the popup window stays on top.

Tested with Python and HTML clients against server all on r20376

[totaam]

2018-09-10 19:19:49: mjharkin uploaded file testJidePopup.zip (3390.7 KiB)

Sample app and screenshots

[totaam]

2018-09-11 07:18:55: antoine changed owner from antoine to mjharkin

[totaam]

2018-09-11 07:18:55: antoine commented

---

Please specify what OS and version you are using, desktop environment and window manager, etc.. (as per ReportingBugs)
I cannot reproduce the problem with Fedora 28 and the latest 2.4 builds.

This is another proprietary toolkit... and they are using "DIALOG" window-type and without the "modal" or "override-redirect" flags:

process_new_common: [5, 1895, 1085, 57, 31, \
    {'size-constraints': {'position': (1895, 1085), 'gravity': 1, 'size': (57, 31)}, \
    'xid': '0xa000ba', 'title': 'JidePopup', 'icon-title': '', \
    'client-machine': 'localhost.localdomain', 'pid': 7496, 'group-leader-xid': 10485939, \
    'window-type': ('DIALOG',), 'decorations': 0, 'skip-taskbar': True, \
    'class-instance': ('sun-awt-X11-XWindowPeer', 'org-eclipse-jdt-internal-jarinjarloader-JarRsrcLoader'), \
    'set-initial-position': True}], \
    ...
    OR=False

Or even the motif wm hints:

_MOTIF_WM_HINTS=MotifWMHints(\
    {'input_mode': ['modeless', 'primary-application-modal'], 'status': 0, \
    'functions': ['all', 'resize'], 'flags': ['functions', 'decorations'], \
    'decorations': ['all', 'border']})

It would not be the first time that AWT does weird things though: Modal dialogs for fullscreen window.

The Xpra client honours modal windows by default in 2.4 and later only, see #1895.

Note: this application is also affected by #1941 since it doesn't use the correct method for asking the window manager to move a window (it manages it itself instead).

[totaam]

2018-09-11 09:09:54: mjharkin commented

---

The server is on Centos7.4 client is Windows 10.
Running in seamless mode (so no desktop env and Xpra is window manager).

I'll try to update this further when I get back to my test pc tonight.

[totaam]

2018-09-11 09:13:44: mjharkin commented

---

Just some more insight also. This popup window also stays on top of all windows from the client side (not just those launched through Xpra).

[totaam]

2018-09-11 13:25:00: antoine commented

---

The server is on Centos7.4 client is Windows 10.
I can reproduce with an mswindows client.
That's because GTK on win32 does this for windows which are set as "DIALOG".

The toolkit is using the wrong window attributes so I was tempted to close this ticket as invalid, but since we already have workaround for AWT (see r11983), r20382 does something similar for this particular case: we switch to "NORMAL" windows instead of "DIALOG" when we detect both AWT and "skip-taskbar" (when running on ms windows only).

@mjharkin: please close if the latest mswindows beta builds ([https://xpra.org/beta/windows/]) work for you. (and I may backport this workaround to older branches)

[totaam]

2018-09-11 15:12:23: mjharkin commented

---

After testing on r20382, I don't think the fix works.

From quick review, when window_type is set to normal I think window_types should also be updated but it isn't, is this correct?

[totaam]

2018-09-11 15:44:38: antoine commented

---

From quick review, when window_type is set to normal I think window_types should also be updated but it isn't, is this correct?
I chose not to modify the data we get from the server (stored in window_types array) and only modify the values within that loop before converting them to a GTK type hint value. I don't see anything wrong with that.

I have just re-tested and toggling the workaround with XPRA_AWT_DIALOG_WORKAROUND=0 reverts to the old behaviour (window on top), so the workaround seems to work as intended for me.

r20386 fixes the GTK3 / Python3 builds - maybe you were trying one of those?

[totaam]

2018-09-11 20:53:34: mjharkin commented

---

Ok, yes the test case provided works with the fix.

The problem is I've badly replicated the issue in the test case.
I'm attaching another test case testJidePop2.jar.
This test case still has the error.
The only difference here is that I've set the owner of the popup to be the main window. I can't see how this effects the outcome in Xpra though.

From Xpra info:

windows.62.XShm=1
windows.62.above=False
windows.62.allowed-actions=('_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE', '_NET_WM_ACTION_RESIZE', '_NET_WM_ACTION_FULLSCREEN', '_NET_WM_ACTION_MINIMIZE', '_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK', '_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT', '_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE', '_NET_WM_ACTION_BELOW')
windows.62.below=False
windows.62.bypass-compositor=0
windows.62.class-instance=('sun-awt-X11-XWindowPeer', 'org-eclipse-jdt-internal-jarinjarloader-JarRsrcLoader')
windows.62.client-geometry=(100, 209, 52, 20)
windows.62.client-machine=ae56dcc0cad6
windows.62.client-properties.da39a3ee5e6b4b0d3255bfef95601890afd80709.screen=0
windows.62.command=
windows.62.decorations=0
windows.62.depth=24
windows.62.focused=False
windows.62.frame=(8, 8, 31, 8)
windows.62.fullscreen=False
windows.62.geometry=(100, 209, 52, 20)
windows.62.grabbed=0
windows.62.has-alpha=False
windows.62.icon-title=
windows.62.iconic=False
windows.62.maximized=False
windows.62.modal=False
windows.62.opacity=-1
windows.62.override-redirect=False
windows.62.pid=2775
windows.62.set-initial-position=True
windows.62.shaded=False
windows.62.shown=True
windows.62.size=(52, 20)
windows.62.size-constraints.gravity=1
windows.62.size-constraints.position=(100, 209)
windows.62.size-constraints.size=(52, 20)
windows.62.skip-pager=False
windows.62.skip-taskbar=True
windows.62.state=('_NET_WM_STATE_SKIP_TASKBAR',)
windows.62.sticky=False
windows.62.title=JidePopup
windows.62.transient-for=61
windows.62.tray=False
windows.62.window-type=('DIALOG',)
windows.62.workspace=65535
windows.62.xid=0xc00020

[totaam]

2018-09-11 20:54:18: mjharkin uploaded file testJidePopup2.jar (1692.7 KiB)

New test case

[totaam]

That's because this new example sets "transient-for", all the window managers that I have tried show the popup on top of its parent window, not just xpra.

Note: on mswindows we also trigger the code from r11983 that I had mentioned in comment:4, you can turn that off with:

set XPRA_UNDECORATED_TRANSIENT_IS_OR=0

But I cannot change this default setting as I don't have access to the application(s) which required this change in the first place (IIRC: matlab).

[totaam]

2018-09-14 08:08:09: mjharkin commented

---

I'll close this as the original test case is fixed.

I've tried to oversimplify the outstanding issue that some windows including Menus and Dialogs after clicking outside them stay above all other windows even windows outside xpra. This is not specific to Jide and I'll create a new ticket for this once I have time to write a better test case.

[totaam]

See also #1980