Hi,
Just recently another problem popped up (at least I did not realize it before, should it have existed for a longer time).
Sometimes when I open a menu and want to select an item, instead of allowing the selection, the menu disappears.
This is the client debug output of such a menu after I click it (and don't move the mouse):
2015-02-18 06:22:34,084 process_new_common: [505, 3326, 48, 142, 96, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xc00e1a', 'pid': -1, 'window-type': ('DROPDOWN_MENU', 'POPUP_MENU', 'NORMAL'), 'maximized': False, 'transient-for': 502, 'override-redirect': True}], OR=True 2015-02-18 06:22:34,085 make_new_window(..) client_window_classes=[<class 'xpra.client.gl.gtk2.gl_client_window.GLClientWindow'>, <class 'xpra.client.gtk2.border_client_window.BorderClientWindow'>], group_leader_window=None 2015-02-18 06:22:34,085 GLClientWindow(..) 2015-02-18 06:22:34,085 <class 'xpra.client.gl.gtk2.gl_client_window.GLClientWindow'>(gtk2.client, None, 505, 3326, 48, 142, 96, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xc00e1a', 'pid': -1, 'window-type': ('DROPDOWN_MENU', 'POPUP_MENU', 'NORMAL'), 'maximized': False, 'transient-for': 502, 'override-redirect': True}, True, {}, (0, 0)) 2015-02-18 06:22:34,085 GLClientWindow(505 : None).apply_transient_for(502) window=GLClientWindow(502 : gtk2.GLWindowBacking(502, (620, 708), YUV444P)) 2015-02-18 06:22:34,086 set_window_type(['DROPDOWN_MENU', 'POPUP_MENU', 'NORMAL']) hints=9 2015-02-18 06:22:34,086 new_backing(142, 96) backing_class=<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'> 2015-02-18 06:22:34,086 make_new_backing(<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'>, 142, 96) effective backing class=<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'>, server alpha=False, window alpha=False 2015-02-18 06:22:34,130 Win32Hooks: window frame size is 4x4 2015-02-18 06:22:34,137 GL do_configure_event(<gtk.gdk.Event at 036888C0: GDK_CONFIGURE x=3326, y=48, width=142, height=96>) 2015-02-18 06:22:34,138 GLClientWindow(505 : gtk2.GLWindowBacking(505, (142, 96), None)).do_map_event(<gtk.gdk.Event at 036888C0: GDK_MAP>) OR=True 2015-02-18 06:22:34,138 GL do_configure_event(<gtk.gdk.Event at 036888C0: GDK_CONFIGURE x=3326, y=48, width=142, height=96>)
Then I move the mouse onto the menu (because I want to select an item) but in that moment the menu disappears. This is the message that appears while this is happening.
2015-02-18 06:22:59,947 destroy_window(505, GLClientWindow(505 : gtk2.GLWindowBacking(505, (142, 96), None))) 2015-02-18 06:22:59,957 cleanup()
I have collected some heuristics on the problem but I am not sure if they are universally valid:
+WIN+Left and then SHIFT+WIN+Right (to move it back), the problem appears. Moving the windows with the mouse to not seem to result in this problem.
xpra server version: 0.14.18 (CentOS 6) xpra client: Xpra 0.15.0, revision 8578, Built on XP-Pro-Dev-VBOX by XP_Pro, 2015-01-29 (i.e., beta)
Which client OS version do you use? This key combination does nothing for me here, but I suspect that virtualbox is intercepting some of the keys.
If at all possible, please capture the -d all
log of just the moment when you move the window right, and then of when you move it back.
For both the client and the server.
Since this does seem to be a focus issue, when the problem occurs, please look at xpra info | egrep "focus|\.title="
.
Can I close this?
Antoine, sorry I didn't have the chance to use this application for some time.
I'll capture the logs and let you know.
For the meantime: Client OS is Win7. The shortcut combination is well known (e.g. http://www.shortcutworld.com/en/win/Windows_7.html). As far as I remember it also worked in Win8 when I used it (I don't remember about WinXP).
Unfortunately you would need two monitors for the combination to work I think. So probably you have just one monitor in VirtualBox?, right?
This is literally impossible: One key stroke and I get thousands of lines running on my screen. Even if I do nothing, it's permanently rolling.
I still did my best to make it possible: On my second screen I opened PuTTY and cygwin shell with "xpra server -d all" and "xpra attach -d all", respectively. I used stderr redirection and "tee" to pipe the messages to an additional log file (both having >1MB in the end!). Then I prepared IrfanView? to make screenshots with Ctrl+F11.
I then prepared an xpra window on one monitor, hit Ctrl+F11 for the first screenshot, Shift+Win+Right to move the window to the second monitor and Shift+Win+Left to move it back, followed by another Ctrl+F11 screenshot.
Based on the screenshots (where I can see the approximate lines of server/client log) I stripped out the relevant section.
So I hope you can find what you are looking for.
Again: Win+Shift+Arrow is a well-known Windows hotkey to move windows between physical monitors. It should actually do the same as dragging the windows manually between screens but it seems there is a difference for xpra.
Thanks for working on this!
Stripped log files: xpra_winshift_client.log, xpra_winshift_server.log
I'll try to setup a multi-monitor MS Windows system to test on.
There's nothing in the log samples that looks suspicious.
You can trim them using:
egrep -v "mask_to_names|texture|gl_|AVImage|Presenting FBO|Switching|OpenGL|GLWindowBacking|draw_region|after_draw_refresh|BGRX" \ xpra_winshift_client.log
Only one thing of interest can be seen with $ grep configure-window ./xpra_winshift_client.log
:
['configure-window', 4, 2572, 293, 781, 657, {'screen': 0}, 0, {}] ['configure-window', 4, 652, 352, 781, 657, {'screen': 0}, 0, {}]
Which looks OK, I guess. ("screen" is a bit confusing term here... we have "display" -> "screen" -> "monitor") The first line looks like the window got moved to the second monitor, then back to the first.
There are a bunch of wndproc
messages received, maybe one of those is relevant.
egrep "position=|set_client_properties|make_keymask_match" xpra_winshift_server.log
.
Again, nothing out of the ordinary here.
Does this happen with 0.14 or just 0.15? There was a change related to how we simulate mouseup when we didn't get the corresponding mousedown event.
Could be related to #911, sounds similar to ticket:759#comment:23
Can I close this?
Hi antoine, it seems I cannot reproduce the behavior any more, but I haven't used the tool as frequently. I can just re-open the ticket again if it pops up again.
Closing and making a note of this in ticket:770#comment:29 - as this may be related and regress.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/814