Red Hat Bugzilla – Bug 974595
When the WIN key is used, depending on the focus, it will not work as expected.
Last modified: 2015-09-22 09:09 EDT
Description of problem: When using the WIN key, with the client or focused inside the virt-viewer guest, the WIN key behaves as expected. If you select the "Windowed" (Not full-screen) virt-viewer icon on the client toolbar, the WIN key shortcuts are sent to the client and guest. However, the client gets the full-shortcut and the virt-viewer guest only displays the Start Menu. Version-Release number of selected component (if applicable): RHEV-M 3.2 (si17.1) and W2K8R2 client. spice-client-msi-3.2-10 (mingw-virt-viewer 0.5.3-25) vdagent-win-0.1-17 to Win7 guest How reproducible: 100% Steps to Reproduce: 1. See above 2. 3. Actual results: Expected results: Additional info:
Created attachment 761309 [details] Screenshot of the WIN+R key combo
Marc-Andre, My assertion is that this is a bug based on either where the focus of the virt-viewer window vs client window (As like in USB-Share) or the case where the focus of the mouse lies. IF the mouse is over the virt-viewer window, it does the proper action within only the virt-viewer. IF the virt-viewer has focus and the mouse is not over the virt-viewer window, both menus are shown. V-V in focus Mouseover V-V V-V Start menu V-V in focus No Mouseover V-V Both V-V and client start menus V-V not in focus Mouseover V-V Client Start menu V-V not in focus No Mouseover V-V Client Start menu We should *not* be getting both start menus when the V-V is in focus and the mouse is not over the V-V window.
Windows sends both the Win key to the client and handle it himself. Should we filter the Win key when we don't have the global hook? I don't think so, this will open new issues with guest bindings, for example.. (you won't be able to have an app handling win+foo unless it has the pointer over) Until we have a strong reason to filter Win key in this case, marking as wontfix.