xpra icon
Bug tracker and wiki

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 Antoine Martin)

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)

xpra-server.log (77.3 KB) - added by antonmos 6 years ago.
xpra-client.log (44.5 KB) - added by antonmos 6 years ago.
delay-focus.patch (1.5 KB) - added by Antoine Martin 5 years ago.
avoids the problem by delaying the focus event

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by antonmos

Attachment: xpra-server.log added

Changed 6 years ago by antonmos

Attachment: xpra-client.log added

comment:1 Changed 6 years ago by antonmos

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

comment:2 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Downloading Intellij now, will test.

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to antonmos
Status: assignednew

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

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

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by antonmos

I have not tested it on non-OSX clients.

Changed 5 years ago by Antoine Martin

Attachment: delay-focus.patch added

avoids the problem by delaying the focus event

comment:7 Changed 5 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from antonmos to Antoine Martin
Status: newassigned

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 Antoine Martin

Owner: changed from Antoine Martin to antonmos
Status: assignednew

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 Antoine Martin

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.