Description of problem: It seems spicec steals keyboard events when the mouse cursor is over the spicec window, even when it doesn't have the mouse grab (there was no click on the window yet or it was ungrabbed by shift-f12). The window manager key bindings don't work until I move the cursor out of the window. This happens to me quite frequently when I'm switching between virtual desktops and spicec is running on one of them. I think spicec should steal the events only when it has the mouse grab, or at least it should be configurable. I'm using openbox with the followMouse focus mode. Version-Release number of selected component (if applicable): spice-client-0.10.1-5.fc17.x86_64 openbox-3.5.0-6.fc17.x86_64 How reproducible: Always. Steps to Reproduce: 1. start spicec 2. "alt-tab" to the spicec window and place the cursor over it (but don't click on it) 3. try to "alt-tab" to another window Actual results: Window manager key bindings don't work. Expected results: They work. Additional info:
Are you running the SPICE agent in your guest (spice-vdagent)? Do you get the same issue with remote-viewer (part of the virt-viewer package)?
How would you pass the key manager events to the guest, if you don't take the keyboard grab? (try spicy with and without SPICE_NOGRAB=1). Perhaps we should have a 2 step mechanism where user would have to click first in the display to take the keyboard grab? I haven't seen that elsewhere, a UI designer could help us to figure what is the best thing to do. (btw, the mouse grab is not taken if the guest runs with agent & qxl driver)
The spice-vdagent service wasn't running in the guest. Installing and starting it doesn't seem to have any effect on this issue. I'm not running X in the guest. spicy with SPICE_NOGRAB doesn't grab the keyboard, but clicking on the window doesn't grab mouse either. I think keyboard grab should be active only with mouse grab, similarly to what qemu does.
(In reply to comment #3) > The spice-vdagent service wasn't running in the guest. Installing and > starting it doesn't seem to have any effect on this issue. I'm not running X > in the guest. > > spicy with SPICE_NOGRAB doesn't grab the keyboard, but clicking on the > window doesn't grab mouse either. Right it disables all grabs, > I think keyboard grab should be active only with mouse grab, similarly to > what qemu does. We don't use mouse grab when your vm has a tablet or the spice-vdagent (and very deliberately so, since the whole mouse grab thing is very user unfriendly), so we cannot make keyboard-grab depend on mouse-grab. Instead we only grab the keyboard when the spice window has keyboard focus, so merely moving the mouse over the window should not grab the keyboard. Unless you're using focus follows mouse, which you are: "I'm using openbox with the followMouse focus mode" So what you're seeing is expected behavior when the keyboard focus is on the spice-window we want for example alt-f4 to close a window inside the guest and not the spice-client window. II can understand us grabbing the keyboard when we get the keyboard focus can be somewhat inconvenient for focus-follows-mouse users, OTOH focus-follows-mouse users should be used to paying attention to where the pointer is when using the keyboard. Note that we cannot wait for a mouse-click, since a user could do alt-tab to the spice-client window, and then for example do alt+f4 as the first thing after the alt+tab. As said this is expected behavior, and I don't see an easy way to make this work better for you -> NOTABUG.
(In reply to comment #4) > (In reply to comment #3) > > I think keyboard grab should be active only with mouse grab, similarly to > > what qemu does. > > We don't use mouse grab when your vm has a tablet or the spice-vdagent > (and very deliberately so, since the whole mouse grab thing is very user > unfriendly), so we cannot make keyboard-grab depend on mouse-grab. qemu seems to do that too, but I have no problem with it stealing the keyboard unexpectedly. It seems the difference is that it grabs the keyboard automatically only with the tablet/spice-agent device and not immediately, but after a short delay (2 seconds?). Would it be possible to implement either of those to spicec? Thanks for looking into this.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I think keyboard grab should be active only with mouse grab, similarly to > > > what qemu does. > > > > We don't use mouse grab when your vm has a tablet or the spice-vdagent > > (and very deliberately so, since the whole mouse grab thing is very user > > unfriendly), so we cannot make keyboard-grab depend on mouse-grab. > > qemu seems to do that too, but I have no problem with it stealing the > keyboard unexpectedly. > > It seems the difference is that it grabs the keyboard automatically only > with the tablet/spice-agent device and not immediately, but after a short > delay (2 seconds?). I just checked the qemu-sdl code and it does no such thing, what it does do is it polls for mouse-events, rather then being event driven like spicec / spice-gtk, and it lowers the polling rate to once every 500 ms when not focussed to save waisting cpu time. This will result in an average delay of grabbing the input when the mouse is over the window of aprox 250 ms. But this is not a consistent delay. Moreover adding such a delay may very well surprise some users in that if they press for example alt+f4 to quickly (which some of them will) that it then closes the client. So this would violate the principle of least surprise. All in all I still believe that what we've now offers the best behavior.
The delay seems to be more longer than one second here (with qemu-system-x86-1.0.1-2.fc17.x86_64), it's enough time to switch to another window or desktop. What about the other option, grabbing mouse only when the tablet/agent is used? I wouldn't mind if it was controlled by an environment option set by default to the current behavior. Perhaps the current behavior is the best one for users which manage their windows by mouse, but I'm not sure it's the best for the keyboard users, the follow focus mode is actually not relevant here. For me, spicec is a "remote qemu" and I think it should behave similarly to avoid suprises like this one.
(In reply to comment #7) > the follow focus mode is actually not relevant here. It is *very* relevant here, we grab the keyboard when we get the keyboard focus, as we want *any* key presses to go to the vm as soon as we have keyboard focus, and that is exactly what we are doing. The idea is that if we are sending keypresses to the guest we better send *all* keypresses to the guest. Your problem is caused by the spice-window *getting* the keyboard focus when you move the mouse over it, which is solely caused by your choice to use focus-follows-mouse. This is very much by design and thus NOTABUG If you think you can improve on this without breaking any usage scenarios for the 9x.xx % of our users not using focus-follows-mouse, then patches are welcome. If you decide to write any patches, then: 1) Please write them against spice-gtk (test with remote-viewer), spicec is obsolete and no longer being developed 2) Please send them to this list (subscription required): http://lists.freedesktop.org/mailman/listinfo/spice-devel For discussion. And no please stop re-opening this bug.
(In reply to comment #8) > Your problem is caused by the spice-window *getting* the keyboard focus when > you move the mouse over it, which is solely caused by your choice to use > focus-follows-mouse. No, not really. I don't touch the mouse at all when I reproduce it. At least here, it happens when spicec was the last window which had focus on a desktop and it is under the mouse cursor when I switch back to that desktop. I think it's just mouse control vs. keyboard control. > And no please stop re-opening this bug. I would if you had addressed my suggestions or stated clearly that you don't want to fix it instead of downplaying it as NOTABUG. Let's close this properly then. Thanks for the suggestions, I'll see if I can prepare a patch to add the new option.