Bug 1261440
| Summary: | Computer went to sleep but screen lock was inhibited? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alan Jenkins <alan.christopher.jenkins> |
| Component: | gnome-shell | Assignee: | Owen Taylor <otaylor> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | alan.christopher.jenkins, fmuellner, klember, mkasik, ofourdan, oholy, otaylor, rstrode, tiagomatos |
| 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: | 2016-07-19 17:50:11 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
Alan Jenkins
2015-09-09 10:43:35 UTC
(In reply to Alan Jenkins from comment #0) > Description of problem: > > I put my computer to sleep.[*] > > When I resumed, I had a new notification (GNOME-style toaster) that said > screen lock had been inhibited by an application. (Didn't say which one). Did it actually say "Lock was blocked by an application" ? That actually means that an application was holding onto a grab, and gnome-shell couldn't show the screen shield. <snip> > Actual results: > - notification warning about inhibited screen-lock on resume Blocked, not inhibited. > - AFAIR the screen-lock was genuinely inhibited, such that I did not have to > enter a password There's no screen lock inhibition in GNOME, or systemd. There's an idle inhibition though. > it's a pity the notification wasn't able to name the app responsible :).
Unfortunately the thing that's blocking screen locking is doing it at the X server level, in a way that gnome can't stop, and the x server doesn't provide a nice mechanism for querying the responsible client.
Right, thanks for your expert help! It didn't say inhibited - that was my word. It did explicitly say ~"by an application". "blocked" sounds about right; I don't know the exact wording though. So from what you're saying - There's no evidence for a bug in g-s-d specifically. - We'd need to see it reproduced with specific steps, then find where the X grab is somehow. - Maybe forget this happened unless it reoccurs. Wayland will change everything anyway :). (In reply to Alan Jenkins from comment #3) > Right, thanks for your expert help! It didn't say inhibited - that was my > word. > > It did explicitly say ~"by an application". "blocked" sounds about right; I > don't know the exact wording though. > > So from what you're saying > > - There's no evidence for a bug in g-s-d specifically. There's no bug in g-s-d at all. > - We'd need to see it reproduced with specific steps, then find where the X > grab is somehow. You'd need to find which application was at fault, indeed. Could be an opened menu in Firefox, or an SDL game running. > - Maybe forget this happened unless it reoccurs. Wayland will change > everything anyway :). Wayland will certainly avoid the screen shield not showing up. Reassigning to gnome-shell for that confusing error message. I understand it might be caused by those things, but I hadn't started any apps. Maybe it was a race condition, i.e. a brief grab during session startup. I said no specific evidence for g-s-d, and it would sound odd. However it's one of the (always) running programs that uses X, so it's among the candidates. Personally I'm not sure how to improve the message. I think the most important thing is to blame an application, which it does. Some people won't know what "lock" means. But if the missing screenlock matters to them, it should be fairly clear from the context. I'm actually quite impressed by the error message (at least that it appears at all :). If people want to reproduce the error message: Maybe try the old gtk newsreader, "pan". pan's File menu blocks screenlock during suspend (as well as alt+tab). I think Firefox stopped using grabs for menus (at least global shortcuts like alt+tab work, which is cool). (In reply to Alan Jenkins from comment #5) > Personally I'm not sure how to improve the message. I think the most > important thing is to blame an application, which it does. It is a shot in the dark as we don't know the actual culprit, however it's the most likely cause and less gibberish than "Something in your session holds a grab and prevents the screen from locking". So I'm not sure either how to do better there ... not sure, but we might be able to get an educated guess from XGetInputFocus Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |