Bug 974595

Summary: When the WIN key is used, depending on the focus, it will not work as expected.
Product: Red Hat Enterprise Virtualization Manager Reporter: Bill Sanford <bsanford>
Component: DocumentationAssignee: Jodi Biddle <jbiddle>
Status: CLOSED NOTABUG QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: acathrow, bsanford, cfergeau, dblechte, gklein, mkrcmari, pvine, sfolkwil, vipatel, yeylon
Target Milestone: ---Keywords: Reopened
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-16 04:42:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of the WIN+R key combo none

Description Bill Sanford 2013-06-14 14:15:38 UTC 
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:
Comment 1 Bill Sanford 2013-06-14 14:17:15 UTC 
Created attachment 761309 [details]
Screenshot of the WIN+R key combo
Comment 5 Bill Sanford 2013-06-14 17:01:00 UTC 
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.
Comment 6 Marc-Andre Lureau 2013-06-14 22:32:15 UTC 
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.