Xpra: Ticket #589: Popup dialog disappears in Intellij IDE (java app)

When trying to use 'Navigate to class' feature in the intellij ide (which is a java awt app), the popup where the user is supposed to type the name of the class pops and disappears immediately. This happens both when I use the shortcut cmnd+N or click it in the menu (Navigate->class).

Server: Centos 6.5, xpra 13.2 in Virtualbox headless
Client: OSX 10.9.3, xpra 13.2 (also tested with 11.6)

Please see attached logs from client and server, and let me know if i can provide any other info.

Thu, 05 Jun 2014 16:37:40 GMT - antonmos: attachment set

Thu, 05 Jun 2014 16:37:50 GMT - antonmos: attachment set

Thu, 05 Jun 2014 16:38:45 GMT - antonmos:

Curiously, this starts happening a few seconds after the app starts up, i.e. it works properly for the first few seconds.

Thu, 05 Jun 2014 16:41:04 GMT - Antoine Martin: owner, status changed

Downloading Intellij now, will test.

Thu, 05 Jun 2014 16:47:13 GMT - antonmos:

One more thing, until i configured "swap-keys=no", when i would hit cmnd+N, the control modifier seemed to get stuck. With "swap-keys=no", i hit ctrl+N and it doenst get stuck any more. Just noticed that holding ctrl+N makes the popup stick around.

Thu, 05 Jun 2014 16:52:14 GMT - Antoine Martin: owner, status changed

Are you saying that this only happens with the OSX client, and only with swap keys enabled?

May be related to: #456 (#567 ?)

Thu, 05 Jun 2014 17:06:18 GMT - antonmos:

No, it is also happening when swap-keys is enabled. I was saying when swap-keys is enabled, control modifier gets stuck, which should potentially be another defect.

Thu, 05 Jun 2014 17:06:56 GMT - antonmos:

I have not tested it on non-OSX clients.

Mon, 09 Jun 2014 10:57:56 GMT - Antoine Martin: attachment set

avoids the problem by delaying the focus event

Mon, 09 Jun 2014 10:58:33 GMT - Antoine Martin: owner, status, description changed

Confirmed with a Linux client.

Here's the relevant part of the server running with -d window:

client configured window 4 - WindowModel(0xa00056 - " "), at: (629, 373, 454, 58)
_process_configure_window([4, 629, 373, 454, 58, {}]) old window geometry: (629, 373, 454, 58)
client configured window 4 - WindowModel(0xa00056 - " "), at: (629, 373, 454, 58)
_process_configure_window([4, 629, 373, 454, 58, {}]) old window geometry: (629, 373, 454, 58)
client mapped window 4 - WindowModel(0xa00056 - " "), at: (629, 373, 454, 58)
reset_x_focus: widget with focus: None
Take Focus -> world window
sendClientMessage(0x40001e, 0x40001e, 0x0, 0x0, WM_PROTOCOLS, WM_TAKE_FOCUS, 118888923, 0, 0, 0)
focus_out_event(<X11:FocusOut {'delivered_to': '0xa00021', 'send_event': 0, 'detail': 4, 'window': '0xa00021', 'mode': 0, 'serial': 11918L, 'type': 10, 'display': ':1'}>) mode=NotifyNormal, detail=NotifyNonlinearVirtual
Giving focus to 0xa00056
... using WM_TAKE_FOCUS
sendClientMessage(0xa00056, 0xa00056, 0x0, 0x0, WM_PROTOCOLS, WM_TAKE_FOCUS, 118888926, 0, 0, 0)
focus_in_event(<X11:FocusIn {'delivered_to': '0xa00056', 'send_event': 0, 'detail': 4, 'window': '0xa00056', 'mode': 0, 'serial': 11932L, 'type': 9, 'display': ':1'}>) mode=NotifyNormal, detail=NotifyNonlinearVirtual
Property changed on 0xa00056: WM_HINTS
wm_hints.input = 0
wm_hints.input = 0
Client window unmapped

The window is unmapped by the application after we reset the focus..
On the client side we see:

set_modal(False) swallowed


focus-out-event for wid=3
GLClientWindow(3 : GLPixmapBacking(3, (1380, 940), GBRP)) focus_change((ClientWindow(3), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=False, _been_mapped=True
update_focus(3, False) focused=3, grabbed=None
focus-in-event for wid=22
GLClientWindow(22 : GLPixmapBacking(22, (454, 58), None)) focus_change((ClientWindow(22), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=True, _been_mapped=True
update_focus(22, True) focused=None, grabbed=None

What happens is that we process the main window's loss of focus before giving the focus to the dialog window (which should be modal... sadly we cannot do application-modal window with gtk).

The patch above seems to avoid the problem, but I want to try to find a better solution.

Mon, 09 Jun 2014 11:22:41 GMT - Antoine Martin: owner, status changed

This should be fixed (somewhat ugly workaround) in r6688.

Can you please confirm so that I can close this ticket and backport it to v0.13? You can find beta win32 and osx builds with this fix here: http://xpra.org/beta/

Thu, 19 Jun 2014 04:16:58 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing. (backport was in r6702 and was released as part of 0.13.4)

Sat, 23 Jan 2021 05:00:13 GMT - migration script:

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