Bug 855523
Summary: | New lock screen does not unlock if an app has the keyboard grabbed when it kicks in | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Hans de Goede <hdegoede> |
Component: | gnome-shell | Assignee: | Owen Taylor <otaylor> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | cfergeau, collura, fmuellner, maverick.pt, maxamillion, mclasen, otaylor, rcrodgers622, samkraju, twaugh, walters |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-15 04:57:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Hans de Goede
2012-09-08 14:26:10 UTC
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. |