Popup dialog disappears in Intellij IDE (java app)

[totaam]

Issue migrated from trac ticket # 589

component: client | priority: major | resolution: worksforme

2014-06-05 17:37:18: antonmos created the issue

---

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.

[totaam]

2014-06-05 17:37:41: antonmos uploaded file xpra-server.log (77.3 KiB)

[totaam]

2014-06-05 17:37:50: antonmos uploaded file xpra-client.log (44.5 KiB)

[totaam]

2014-06-05 17:38:46: antonmos commented

---

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

[totaam]

2014-06-05 17:41:04: totaam changed status from new to assigned

[totaam]

2014-06-05 17:41:04: totaam changed owner from antoine to totaam

[totaam]

2014-06-05 17:41:04: totaam commented

---

Downloading Intellij now, will test.

[totaam]

2014-06-05 17:47:13: antonmos commented

---

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.

[totaam]

2014-06-05 17:52:14: totaam changed status from assigned to new

[totaam]

2014-06-05 17:52:14: totaam changed owner from totaam to antonmos

[totaam]

2014-06-05 17:52:14: totaam commented

---

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

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

[totaam]

2014-06-05 18:06:18: antonmos commented

---

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.

[totaam]

2014-06-05 18:06:56: antonmos commented

---

I have not tested it on non-OSX clients.

[totaam]

2014-06-09 11:57:56: totaam uploaded file delay-focus.patch (1.5 KiB)

avoids the problem by delaying the focus event

[totaam]

2014-06-09 11:58:33: totaam changed status from new to assigned

[totaam]

2014-06-09 11:58:33: totaam changed owner from antonmos to totaam

[totaam]

2014-06-09 11:58:33: totaam edited the issue description

[totaam]

2014-06-09 11:58:33: totaam commented

---

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..
[[BR]]
On the client side we see:

set_modal(False) swallowed

And:

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
send_focus(0)
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
send_focus(22)

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.

[totaam]

2014-06-09 12:22:41: totaam changed status from assigned to new

[totaam]

2014-06-09 12:22:41: totaam changed owner from totaam to antonmos

[totaam]

2014-06-09 12:22:41: totaam commented

---

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/]

[totaam]

2014-06-19 05:16:58: totaam changed status from new to closed

[totaam]

2014-06-19 05:16:58: totaam changed resolution from ** to worksforme

[totaam]

2014-06-19 05:16:58: totaam commented

---

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