The new lock screen seems to kick in, even if an app has the keyboard grabbed, and then one cannot unlock as that requires using the keyboard. For example, connect to a spice using vm using remote-viewer, and go fullscreen. Then press for example ctrl+alt+l to verify the keyboard is grabbed (the guest will lock rather then the client machine). And then wait for lock timeout minutes until the lock screen kicks in. Try to get the unlock dialog by hitting esc: nothing happens. gnome-screen-saver used to simply not lock when app has the keyboard grabbed, I believe that to be the better behaviour (neither is ideal, but well X11 keyboard grabs just are not ideal)
We have been dinged several times over the years for the screensaver not kicking in when a grab is held, so I consider this a feature, not a bug.
(In reply to comment #1) > We have been dinged several times over the years for the screensaver not > kicking in when a grab is held, so I consider this a feature, not a bug. Erm, it kicks in but it is impossible to unlock it, how on earth is that not a bug ? It makes it impossible to use the system after it has been locked ... (yeah I know I can kill gnome-shell from a text vc, but an ordinary user won't).
Yes, that part is a bug.
(In reply to comment #3) > Yes, that part is a bug. And how do you suggest to solve that bug without simply not locking when gnome-shell cannot grab the keyboard ? Note that the mouse may be grabbed to, at which point there will be no way to interact with gnome-shell to release the lock. Likely there is a way to make the app holding both locks release them, but that usually requires actually seeing the app to be able to properly interact with it ...
To fix it properly requires grab overrides in X
(In reply to comment #5) > To fix it properly requires grab overrides in X <sigh>I know, but those exist yet. So currently we've to choose between: a) Not locking when a grab is active; or b) Users being unable to unlock, and ending up power-cycling there machine loosing all open work (assuming a non technical users) Of which *a* clearly is the better option. I must say I'm a bit mystified we're even having this discussion at all, clearly b is completely unacceptable and unusable behavior!
gnome-shell-3.6.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-shell-3.6.3-1.fc18
gnome-shell-3.6.3-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-shell-3.6.3-2.fc18
gnome-shell-3.6.3-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Several months in to the released FC18, I hit this issue on a regular basis. In fact, over the last week or so I've hit some rather interesting user interface bugs with FC18, the most annoying of which is being unable to unlock the lock screen because something theoretically has grabbed the keyboard. But I'm also, at this very moment, after finding a work around (clicking on Login as different user, then reselecting my only non-root user on the system) unable to interact with any of the open windows (including Chrome which I'm using to make this comment) with the mouse. I can move my cursor around on screen just fine, but clicking any mouse button fails to result in any action at all. No window switching, no link activations, not even context menus with the right mouse button. To eliminate the mouse as the cause, I plugged in a Bluetooth adapter I use for a mouse for my laptop, and I get the exact same behavior. Oddly, the mice work just fine in console #2 though they are completely useless at the moment in X/gnome. Please test for a reversion on this bug.