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.
Curiously, this starts happening a few seconds after the app starts up, i.e. it works properly for the first few seconds.
Downloading Intellij now, will test.
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.
Are you saying that this only happens with the OSX client, and only with swap keys enabled?
May be related to: #456 (#567 ?)
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.
I have not tested it on non-OSX clients.
avoids the problem by delaying the focus event
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
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.
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/
Not heard back, closing. (backport was in r6702 and was released as part of 0.13.4)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/589