Red Hat Bugzilla – Bug 1286785
Unable to re-select full-screen guest with spice-server by mouse click when switching between dual-head display.
Last modified: 2017-03-16 12:53:13 EDT
Description of problem: In dual display, on one display guest is running in full screen mode. After working on other display when we try to enter guest by mouse click, no tab is selected and to enter guest we have to either use ALT+TAB or manually select guest tab from all available tabs from host. Version-Release number of selected component (if applicable): spice-server-0.12.4-15.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Open full-screen guest using spice server in one display 2. Click on other display 3. Try to enter guest by mouse click Actual results: No tab is selected Expected results: Guest (tab) should be selected Additional info: Works fine when using VNC server in full screen mode. Also works when running guest in maximized mode irrespective of whether using spice server or VNC server.
spice-gtk / virt-viewer versions would be useful.
spice-gtk3-0.26-5.el7.x86_64 virt-viewer-2.0-6.el7.x86_64 As mentioned in additional info, this issue is reproducible using virt-viewer in full screen mode with Spice server only but it does not reproduce with virt-viewer in full screen mode with VNC server.
I can reproduce it with rhel7.2 release version. spice-gtk3-0.26-5.el7.x86_64 virt-viewer-2.0-6.el7.x86_64 Steps to Reproduce: 1. Prepare a spice guest, open it by virt-viewer. 2. Move the guest display to the secondary monitor and make it to fullscreen mode. 3. Open a terminal in the guest and type some characters to make the keyboard works. 4. Move the mouse pointer to primary monitor and click the **desktop** of the primary monitor. 5. Move the mouse pointer to the secondary monitor and click the terminal in the guest. 6. Type some characters. Actual Result: The keyboard doesn't work.
Additional info: This issue doesn't occur on rhel6 or vnc client on rhel7.
Hi, I think the problem is somewhere else if the app is not selected by the window manager. Please, provide debug logs: virt-viewer --debug --spice-debug Thanks
Created attachment 1129233 [details] spice debug log
Created attachment 1130808 [details] gtk app to reproduce the problem Simple gtk program to reproduce the issue. It works similar as spice-gtk widget.
I was able to reproduce the problem using a simple gtk program - please see attachment. In full-screen mode it stops receiving focus in events after a while. And a window which is below the full-screen window will get focus instead. rpm -q gtk3 gtk3-3.14.13-16.el7.x86_64 Reassigning to gtk for investigation
Created attachment 1130811 [details] screencast of the focus issue Screencast for the comment 13. After 30s the "fullscreen program" stopped receiving focus events when clicking on it. Nautilus window which was below it got focus instead.
This looks very similar to Bug 1167889. (by the way, I re-assigned that one to mutter since I assumed it was the window manager's responsibility)
What makes you think that this is a gtk issue ?
Moving to mutter, which seems more likely to be responsible.
(In reply to Jonathon Jongsma from comment #16) > This looks very similar to Bug 1167889. This may indeed be the same issue. Unfortunately I don't have a non-VM RHEL system at hand for testing, so it'd be appreciated if someone could test whether the issue is reproducible with mutter-3.14.4-21.el7.
1. I can't reproduce it by only upgrading clutter and mutter. 2. And i found keep clutter and mutter as old version, then only upgrade spice-* to latest version, and cannot reproduce it either. $ rpm -qa | grep spice spice-glib-0.31-2.el7.x86_64 spice-gtk-0.31-2.el7.x86_64 spice-server-0.12.4-17.el7.x86_64 spice-protocol-0.12.11-1.el7.noarch spice-vdagent-0.14.0-10.el7.x86_64 spice-gtk3-0.31-2.el7.x86_64
Comment #22 suggests that this issue is no longer reproducible in RHEL 7.3. Is this the case?
Thank you for the confirmation. I'll close the issue as a duplicate then, please re-open if the customer experience the problem again on RHEL 7.3. *** This bug has been marked as a duplicate of bug 1167889 ***