Bug 857389 - Keyboard input focus broken (mostly win key captured by both guest and client)
Summary: Keyboard input focus broken (mostly win key captured by both guest and client)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Marc-Andre Lureau
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 873341 973652
TreeView+ depends on / blocked
 
Reported: 2012-09-14 10:00 UTC by Tomas Jamrisko
Modified: 2013-06-12 12:42 UTC (History)
5 users (show)

Fixed In Version: mingw-virt-viewer-0.5.3-15.el6
Doc Type: Bug Fix
Doc Text:
Previously, when connecting Windows 7 (or 8) guests with Windows 7 (or 8) clients, the 'Windows' key would be captured by both the guest and the client instead of being passed solely to the guest. This error has now been corrected so that the 'Windows' key is captured only by the guest when the cursor is within the remote-viewer window.
Clone Of:
: 873341 (view as bug list)
Environment:
Last Closed: 2012-12-04 17:58:57 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:1525 0 normal SHIPPED_LIVE new package: mingw-virt-viewer 2012-12-04 22:56:09 UTC

Description Tomas Jamrisko 2012-09-14 10:00:44 UTC
Description of problem:

This might actually be two seperate bugs, but one of them appears at random, and they seem to be pretty closely related.

Connecting to a guest with cursor in client mode can result in keyboard focus behaving somewhat strangely: 
 -- win key captured both by client and guest
 -- (the random, barely reproducible) input redirected to guest even though virt-viewer doesn't appear to be focused (a different client side application should have the keyboard focus)

Version-Release number of selected component (if applicable):
mingw-virt-viewer 0.5.3

How reproducible:
Always (win key)


Steps to Reproduce:
1. Connect to a Windows 7 (or 8) guest (preferably with 2 monitors) with a windows 7 (or 8) client
2. Focus on a different application on clients side (don't have virt-viewer focused), move cursor out of the virt-viewer
3. alt+tab to virt-viewer (cursor still out of the window)
4. hit win key
  
Actual results:
Windows key gets grabbed both by client and guest. 

Expected results:
Win key is captured just by guest

Additional info:
If you're lucky you'll notice the other bug as well (client applications won't be receiving input)

Comment 1 Marc-Andre Lureau 2012-10-29 18:11:55 UTC
I can reproduce weird key grab issues too.

Comment 2 Marc-Andre Lureau 2012-10-31 15:51:28 UTC
sent patch to ML

Comment 3 Tomas Jamrisko 2012-11-02 16:44:11 UTC
Win-key still gets grabbed by both client and guest when keyboard focus is in remote-viewer window, but mouse cursor is somewhere outside of it. 

Everything works fine otherwise. 

Is it a use case worth additional fixing?

Comment 4 Marc-Andre Lureau 2012-11-02 20:02:51 UTC
(In reply to comment #3)
> Win-key still gets grabbed by both client and guest when keyboard focus is
> in remote-viewer window, but mouse cursor is somewhere outside of it. 
> 
> Everything works fine otherwise. 
> 
> Is it a use case worth additional fixing?

Yeah, received by both is a bug. I'll look into it.

Comment 5 Uri Lublin 2012-11-05 15:23:48 UTC
This bug is partially fixed:
 (1). remote-viewer window is in focus (cursor inside window): fixed.
    before the fix windows-key is captured by both guest and client.
    after  the fix windows-key is captured only by guest, as expected.
 (2). remote-viewer window is not in focus (cursor outside windows) not fixed.
    windows-key is captured by both guest and client.

I'm going to mark this bug as fixed for case (1) above, and clone it for case (2).

Comment 9 errata-xmlrpc 2012-12-04 17:58:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1525.html


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