Description

Another Java issue:
When running the attached example: java -jar menuOnTop.jar
If you open the menu and click outside of any other xpra window (set_focus(0)) then the menu remains on top of all other windows. See attached screenshot.

Not sure if it's this problem, but AWT menus seem to open with DIALOG window type instead of POPUP_MENU:

Change History (10)

I believe this is due to grab handling (see #139, ticket:705#comment:7).
Java must be grabbing the pointer, expecting to receive the click outside the drop down menu window.
Since we're forwarding the window to a different display server, we may never get the click event, only a loss of focus. Most toolkits will handle that just fine, but Java is different...

Your patch looks a little bit dangerous to me, I remember testing something similar and causing crashes.
At least, I believe that the check should be modified to only affect OR windows since the drop down menu uses that. And it should be possible to disable this behaviour using an environment variable if this is to be enabled by default.

Ideally, this would be fixed server side by causing the grab to be broken and making Java notice it. I've tried using xdotool key XF86Ungrab but this didn't help.
Looking at ​XUngrabPointer: The X server performs an UngrabPointer request automatically if the event window or confine_to window for an active pointer grab becomes not viewable or if window reconfiguration causes the confine_to window to lie completely outside the boundaries of the root window - we can't "randomly" make windows hidden and hope that's going to help either. (we don't even know when they expect to hold a grab..)

The Java source around grabs reads: We should always grab both keyboard and pointer to control event flow on popups. This also simplifies synthetic grab implementation. The active grab overrides activated automatic grab.

I patched your source code right at the start of initialize() to add debug logging to AWT X11:

I'll look at trying something on the server side over the weekend.
For now, the best I've got is this which is quite a bit safer and works well apart from 2 clicks are need to enter the menu again.
It's also very close to what's actually happening at least from the perspective of the xpra windows.

I don't think so: we can't just send click events at 0,0 whenever we get lost focus events as that would wreak havoc with many well behaved applications that do have windows mapped in the top left corner. (ie: OR fullscreen windows)

The w.destroy() solution is actually safer, as it is more targeted.

A better solution might be to automatically grab the pointer (and keyboard?) whenever we see an override-redirect AWT window. The AWT window would then receive the button events outside the window area.

I believe r20608 solves this problem for win32 clients much more cleanly: we force a pointer grab when we find an AWT override redirect window.
And maybe we should apply this workaround to more than just Java's windows.. (the env var XPRA_OR_FORCE_GRAB makes it easier to test at runtime)

For X11 clients, this is a bit more complicated: we were breaking the grab when we got focus change events.r20609 looks correct, but this is the sort of change that makes me nervous: this "bug" had been there since r12645 (more than 2 years ago) and could cause regressions.