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
Steps to Reproduce:
1. See above
Created attachment 761309 [details]
Screenshot of the WIN+R key combo
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.