Bug 855523 - New lock screen does not unlock if an app has the keyboard grabbed when it kicks in
New lock screen does not unlock if an app has the keyboard grabbed when it ki...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-08 10:26 EDT by Hans de Goede
Modified: 2014-09-13 14:57 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-14 23:57:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2012-09-08 10:26:10 EDT
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)
Comment 1 Matthias Clasen 2012-09-26 20:55:38 EDT
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.
Comment 2 Hans de Goede 2012-09-27 03:50:19 EDT
(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).
Comment 3 Matthias Clasen 2012-09-28 14:03:12 EDT
Yes, that part is a bug.
Comment 4 Hans de Goede 2012-09-28 14:09:23 EDT
(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 ...
Comment 5 Matthias Clasen 2012-10-04 22:55:45 EDT
To fix it properly requires grab overrides in X
Comment 6 Hans de Goede 2012-10-05 07:43:32 EDT
(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!
Comment 7 Fedora Update System 2013-02-13 16:05:25 EST
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
Comment 8 Fedora Update System 2013-02-14 03:50:35 EST
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
Comment 9 Fedora Update System 2013-02-14 23:57:12 EST
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.
Comment 10 Raymond Rodgers 2013-05-07 23:31:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.