xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 4 years ago

#814 closed defect (fixed)

Menus cannot be clicked sometimes (after using SHIFT+WIN+Arrows?)

Reported by: Lukas Haase Owned by: Lukas Haase
Priority: critical Milestone: 0.16
Component: client Version: trunk
Keywords: Cc:

Description

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)

Attachments (2)

xpra_winshift_client.log (30.7 KB) - added by Lukas Haase 5 years ago.
xpra_winshift_server.log (52.9 KB) - added by Lukas Haase 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by Antoine Martin

Milestone: 0.14
Owner: changed from Antoine Martin to Lukas Haase

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

comment:2 Changed 5 years ago by Antoine Martin

Can I close this?

comment:3 Changed 5 years ago by 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?

comment:4 Changed 5 years ago by Lukas Haase

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

Changed 5 years ago by Lukas Haase

Attachment: xpra_winshift_client.log added

Changed 5 years ago by Lukas Haase

Attachment: xpra_winshift_server.log added

comment:5 Changed 5 years ago by Antoine Martin

Milestone: 0.140.16
Status: newassigned

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.

comment:6 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Lukas Haase
Status: assignednew

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

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 4 years ago by Antoine Martin

Priority: majorcritical

Can I close this?

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.