Xpra: Ticket #1955: Jide Popup Always on Top

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

Mon, 10 Sep 2018 18:19:48 GMT - Mark Harkin: attachment set

Sample app and screenshots

Tue, 11 Sep 2018 06:18:55 GMT - Antoine Martin: owner changed

Please specify what OS and version you are using, desktop environment and window manager, etc.. (as per wiki/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 even the motif wm hints:

    {'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: <AWT Dev> 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).

Tue, 11 Sep 2018 08:09:54 GMT - Mark Harkin:

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.

Tue, 11 Sep 2018 08:13:43 GMT - Mark Harkin:

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

Tue, 11 Sep 2018 12:25:00 GMT - Antoine Martin:

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)

Tue, 11 Sep 2018 14:12:22 GMT - Mark Harkin:

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?

Tue, 11 Sep 2018 14:44:37 GMT - Antoine Martin:

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?

Tue, 11 Sep 2018 19:53:33 GMT - Mark Harkin:

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.class-instance=('sun-awt-X11-XWindowPeer', 'org-eclipse-jdt-internal-jarinjarloader-JarRsrcLoader')
windows.62.client-geometry=(100, 209, 52, 20)
windows.62.frame=(8, 8, 31, 8)
windows.62.geometry=(100, 209, 52, 20)
windows.62.size=(52, 20)
windows.62.size-constraints.position=(100, 209)
windows.62.size-constraints.size=(52, 20)

Tue, 11 Sep 2018 19:54:17 GMT - Mark Harkin: attachment set

New test case

Thu, 13 Sep 2018 14:11:42 GMT - Antoine Martin:

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:


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

Fri, 14 Sep 2018 07:08:09 GMT - Mark Harkin: status changed; resolution set

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.

Wed, 19 Feb 2020 11:44:21 GMT - Antoine Martin:

See also #1980

Sat, 23 Jan 2021 05:38:16 GMT - migration script:

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