Opened 6 years ago
Closed 5 years ago
#589 closed defect (worksforme)
Popup dialog disappears in Intellij IDE (java app)
Reported by: | antonmos | Owned by: | antonmos |
---|---|---|---|
Priority: | major | Milestone: | 0.14 |
Component: | client | Version: | 0.13.x |
Keywords: | Cc: |
Description (last modified by )
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.
Attachments (3)
Change History (12)
Changed 6 years ago by
Attachment: | xpra-server.log added |
---|
Changed 6 years ago by
Attachment: | xpra-client.log added |
---|
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
Downloading Intellij now, will test.
comment:3 Changed 6 years ago by
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.
comment:4 Changed 6 years ago by
Owner: | changed from Antoine Martin to antonmos |
---|---|
Status: | assigned → new |
comment:5 Changed 6 years ago by
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.
Changed 5 years ago by
Attachment: | delay-focus.patch added |
---|
avoids the problem by delaying the focus event
comment:7 Changed 5 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from antonmos to Antoine Martin |
Status: | new → assigned |
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.
comment:8 Changed 5 years ago by
Owner: | changed from Antoine Martin to antonmos |
---|---|
Status: | assigned → new |
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/
comment:9 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Not heard back, closing. (backport was in r6702 and was released as part of 0.13.4)
Curiously, this starts happening a few seconds after the app starts up, i.e. it works properly for the first few seconds.