Red Hat Bugzilla – Bug 1429611
Alt-tab in multimonitor fullscreen is processed by client
Last modified: 2018-05-15 14:03:13 EDT
ALT-TAB menu of Client is displayed in fullscreen mode. Guest is Windows7_64 or RHEL74. Client is: spice-client-msi-x86-4.1-6.el7ev.noarch How reproducible: always 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 ALT-TAB Actual results: ALT-TAB menu of Client is displayed. Expected results: ALT-TAB menu of Guest should be displayed. Additional info: There was a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1322914 This bug is different from previous bug in step #5.
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@redhat.com> 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@redhat.com>
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@redhat.com> - 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