Bug 974595 - When the WIN key is used, depending on the focus, it will not work as expected.
When the WIN key is used, depending on the focus, it will not work as expected.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Jodi Biddle
ecs-bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-14 10:15 EDT by Bill Sanford
Modified: 2015-09-22 09 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-16 00:42:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of the WIN+R key combo (1.35 MB, image/png)
2013-06-14 10:17 EDT, Bill Sanford
no flags Details

  None (edit)
Description Bill Sanford 2013-06-14 10:15:38 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:
Comment 1 Bill Sanford 2013-06-14 10:17:15 EDT
Created attachment 761309 [details]
Screenshot of the WIN+R key combo
Comment 5 Bill Sanford 2013-06-14 13:01:00 EDT
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 18:32:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.