Xpra: Ticket #814: Menus cannot be clicked sometimes (after using SHIFT+WIN+Arrows?)

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:

If this happens, it helps to click on a non-xpra window (give it the focus) and then back. Then the menu works again. Another xpra window does not seem to be enough
If this happens, all menus in all windows are broken. Once I click on a non-xrpa Windows window and back, the menus are working again.
It seems that I can reproduce the behavior by moving windows between different monitors: When I move a window from monitor 1 to monitor 2 and back, I cannot click the menus any more
Interestingly, this only seems to happen if the windows are moved with SHIFT+WIN+Arrow-Key. For example, if I have a window on monitor 1 and I do SHIFT

+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)

Wed, 18 Feb 2015 09:02:53 GMT - Antoine Martin: owner changed; milestone set

owner changed from Antoine Martin to Lukas Haase
milestone set to 0.14

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=".

Sat, 21 Mar 2015 17:49:55 GMT - Antoine Martin:

Can I close this?

Sat, 21 Mar 2015 21:35:35 GMT - Lukas Haase:

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?

Sun, 22 Mar 2015 03:48:15 GMT - Lukas Haase: owner changed

owner changed from Lukas Haase to Antoine Martin

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

Sun, 22 Mar 2015 03:49:09 GMT - Lukas Haase: attachment set

attachment set to xpra_winshift_client.log

Sun, 22 Mar 2015 03:49:28 GMT - Lukas Haase: attachment set

attachment set to xpra_winshift_server.log

Fri, 24 Apr 2015 12:07:45 GMT - Antoine Martin: status, milestone changed

status changed from new to assigned
milestone changed from 0.14 to 0.16

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:

client log:

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.

the server log with egrep "position=|set_client_properties|make_keymask_match" xpra_winshift_server.log.

Again, nothing out of the ordinary here.

Fri, 23 Oct 2015 06:17:46 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to Lukas Haase
status changed from assigned to new

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

Sat, 05 Dec 2015 10:51:45 GMT - Antoine Martin: priority changed

priority changed from major to critical

Can I close this?

Sun, 06 Dec 2015 02:21:27 GMT - Lukas Haase:

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.

Tue, 08 Dec 2015 05:11:42 GMT - Antoine Martin: status changed; resolution set

status changed from new to closed
resolution set to fixed

Closing and making a note of this in ticket:770#comment:29 - as this may be related and regress.

Sat, 23 Jan 2021 05:06:49 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/814