xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 4 years ago

Closed 4 years ago

Last modified 16 months ago

#1955 closed defect (fixed)

Jide Popup Always on Top

Reported by: Mark Harkin Owned by: Mark Harkin
Priority: major Milestone: 2.4
Component: server Version: trunk
Keywords: Cc:


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

Attachments (2)

testJidePopup.zip (3.3 MB) - added by Mark Harkin 4 years ago.
Sample app and screenshots
testJidePopup2.jar (1.7 MB) - added by Mark Harkin 4 years ago.
New test case

Change History (13)

Changed 4 years ago by Mark Harkin

Attachment: testJidePopup.zip added

Sample app and screenshots

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Mark Harkin

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

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

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

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

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

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

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

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

Changed 4 years ago by Mark Harkin

Attachment: testJidePopup2.jar added

New test case

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

comment:9 Changed 4 years ago by Mark Harkin

Resolution: fixed
Status: newclosed

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.

comment:10 Changed 2 years ago by Antoine Martin

See also #1980

comment:11 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.