xpra icon
Bug tracker and wiki

Opened 2 months ago

Closed 2 months ago

#1955 closed defect (fixed)

Jide Popup Always on Top

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

Description

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 mjharkin 2 months ago.
Sample app and screenshots
testJidePopup2.jar (1.7 MB) - added by mjharkin 2 months ago.
New test case

Change History (11)

Changed 2 months ago by mjharkin

Attachment: testJidePopup.zip added

Sample app and screenshots

comment:1 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to mjharkin

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=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: <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 2 months ago by mjharkin

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 2 months ago by mjharkin

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 2 months 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 2 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 2 months ago by mjharkin

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 2 months 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 2 months ago by mjharkin

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

Changed 2 months ago by mjharkin

Attachment: testJidePopup2.jar added

New test case

comment:8 Changed 2 months 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:

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

comment:9 Changed 2 months ago by mjharkin

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.

Note: See TracTickets for help on using tickets.