Bug 974595 - When the WIN key is used, depending on the focus, it will not work as expected.
Summary: When the WIN key is used, depending on the focus, it will not work as expected.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.3.0
Assignee: Jodi Biddle
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-14 14:15 UTC by Bill Sanford
Modified: 2015-09-22 13:09 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-16 04:42:47 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


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

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.


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