Bug 1429611
| Summary: | Alt-tab in multimonitor fullscreen is processed by client | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Andrei Stepanov <astepano> | ||||||
| Component: | mingw-virt-viewer | Assignee: | Default Assignee for SPICE Bugs <rh-spice-bugs> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | SPICE QE bug list <spice-qe-bugs> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 4.1.0 | CC: | apinnick, astepano, bsanford, cfergeau, lsurette, rbalakri, rh-spice-bugs, srevivo, ssheribe, tpelka, victortoso | ||||||
| Target Milestone: | ovirt-4.2.0 | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | mingw-virt-viewer-2.0-14.el7ev mingw-spice-gtk-0.31-7.el7ev | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Previously, when multiple monitors were used in full screen mode, an application would lose the keyboard grab, so that keyboard input went to the client instead of the guest. The current release ensures that the keyboard grab/ungrab is triggered by the window's focus events, so that keyboard input goes to the guest.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2018-05-15 18:02:00 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Spice | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrei Stepanov
2017-03-06 16:56:29 UTC
Created attachment 1260475 [details]
RV log
Keyboard grab is broken, what is client OS? Is it regression? Snir, do you have a suggestion - it should be covered by your patch https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=143ebfdf275a7743ca4332dc526991f8bd95124a Andrei, we need full spice-gtk debug, try `set SPICE_DEBUG=1` instead of `remote-viewer --spice-debug` Created attachment 1260733 [details]
remote-viewer run with set SPICE_DEBUG=1
Client is Windows10 32Bit I cannot reproduce this bug with RHEL73 client: spice-gtk3-0.31-6.el7_3.2.x86_64 spice-glib-0.31-6.el7_3.2.x86_64 spice-protocol-0.12.11-1.el7.noarch virt-viewer-2.0-12.el7.x86_64 (In reply to Andrei Stepanov from comment #3) > Created attachment 1260733 [details] > remote-viewer run with set SPICE_DEBUG=1 (remote-viewer.exe:130440): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed It can be a Windows feature or a GTK feature Can you check the same client on Win7 ? Thanks I'm able to reproduce this with spice-client-msi-4.1-6 on windows 7x64 guest and windows 7x64 client. I can also reproduce this with latest upstream. So we also need to fix this upstream. Andrei, could please reply to comment #2 about regression? Yes, reproduced on upstream for me too.. It seems like the focus catching on windows doesn't behave nicely as on linux. after some playing it's seems like the guest receives the alt-tab only when moving to display 2 is done by using alt-tab at the client (clicking is not enough for some reason) Win7 client has the same problem. Tested with: Widnows 7 x86 + spice-client-msi-x86-4.1-6.el7ev.noarch Proposed patch fixes the issue. https://lists.freedesktop.org/archives/spice-devel/2017-June/037897.html Additional info. This bug is has the same behavior for WIN key. Steps to Reproduce: 1. Have a client with 2 displays. 2. Connect to VM in full-screen. Open some applications in guest VM, like a text editor, calculator browser, etc. 3. Click with a mouse in display#1. 4. Move with mouse cursor to either display of guest. 5. Click with a mouse in display#2. 6. Press WIN key. Actual results: WIN key processed by client. (In reply to Andrei Stepanov from comment #11) > Additional info. > > This bug is has the same behavior for WIN key. > > > Steps to Reproduce: > 1. Have a client with 2 displays. > 2. Connect to VM in full-screen. Open some applications in guest VM, like a > text editor, calculator browser, etc. > 3. Click with a mouse in display#1. > 4. Move with mouse cursor to either display of guest. > 5. Click with a mouse in display#2. > 6. Press WIN key. > > Actual results: WIN key processed by client. Indeed (and proposed patch should fix it also in this case). Patch upstream:
commit 178fe41e9fb8a50b72155becdd367820c88ef177
Author: Snir Sheriber <ssheribe>
Date: Tue Jun 6 10:19:34 2017 +0300
Grab keyboard based on focus in windows client
Currently the client grabs keyboard based on session focus, on windows
environment gtk sends grab_broken if wm_killfocus is received (when
focus is changed) while the application has the grab. It means that
when grab is based on the session, clicking inside focusless window
will cause wm_killfocus to be sent towards the focused window, this
will generate grab_broken event which follows by no grab at all.
This patch expands the solution presented in 143ebfd to work also on
windows client without causing grab_broken event.
This is implemented a bit differently from linux, if on mouse entrance
session already has focus, focus will be set to the current window,
this will generate focus events that will release and take grab again
without grab_broken event.
Resolves: rhbz#1429611
Related: rhbz#1275231
Acked-by: Victor Toso <victortoso>
This bug is in modified status but no patches are attached to it. Can you please check if the fix is included in latest build and move to QE if so? (In reply to Sandro Bonazzola from comment #14) > This bug is in modified status but no patches are attached to it. > Can you please check if the fix is included in latest build and move to QE > if so? Changelog from 0.31-7.el7 build (in the Fixed in Version) * Thu Nov 30 2017 Victor Toso <victortoso> - 0.31-7 - Grab keyboard based on focus in windows client Resolves: rhbz#1429611 - Do not hide devices on client if USB Resolves: rhbz#1431137 - Fix device arrival event logic Resolves: rhbz#1425961 See: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629187 This fix is also in the latest build, 0.31-8.el7 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. https://access.redhat.com/errata/RHBA-2018:1543 BZ<2>Jira Resync |