Bug 1261440 - Computer went to sleep but screen lock was inhibited?
Computer went to sleep but screen lock was inhibited?
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-09 06:43 EDT by Alan Jenkins
Modified: 2016-07-19 13:50 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 13:50:11 EDT
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 Alan Jenkins 2015-09-09 06:43:35 EDT
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).

*I do not recall having to enter my password on resume*.




[*] By shutting the lid.  I believe this was immediately after logging in, after a reboot-and-install-updates.  Unfortunately I can't find what the updated packages were.

Version-Release number of selected component (if applicable):
gnome-settings-daemon-3.16.3-1.fc22.x86_64

How reproducible:
I'm reporting this immediately, as an apparent logic error that this can ever happen.

Steps to Reproduce: unknown

Actual results:
- notification warning about inhibited screen-lock on resume
- AFAIR the screen-lock was genuinely inhibited, such that I did not have to enter a password

Expected results:

- System sleep should always lock active sessions (unless user has tampered with defaults).
- If we then ignore a lock-inhibit in the process, that's fine.  There would be no notification to the user about it; it's just not needed.

- It's also a pity that the notification didn't show any information about what had blocked the screen-lock.

Note that systemd inhibits do a great job of explaining themselves (in systemd-inibit --list).  I know GNOME app inhibits aren't the same thing, but it's a pity the notification wasn't able to name the app responsible :).

I didn't have any windows open or anything really.  The source of the inhibit is a bit mysterious.

Additional info:

- Hopefully apps consider whether they just want to stop screenlock-on-timeout, or if they need to stop user-initiated sleep as well.  So it won't matter that the screen is getting locked on sleep, even though some app requested a screen-lock inhibit.
Comment 1 Bastien Nocera 2015-09-11 07:00:36 EDT
(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.
Comment 2 Ray Strode [halfline] 2015-09-11 08:05:57 EDT
> 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.
Comment 3 Alan Jenkins 2015-09-11 09:24:33 EDT
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 :).
Comment 4 Bastien Nocera 2015-09-11 11:11:41 EDT
(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.
Comment 5 Alan Jenkins 2015-09-12 05:52:01 EDT
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).
Comment 6 Florian Müllner 2015-09-18 08:48:56 EDT
(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 ...
Comment 7 Ray Strode [halfline] 2015-09-18 10:26:49 EDT
not sure, but we might be able to get an educated guess from XGetInputFocus
Comment 8 Fedora End Of Life 2016-07-19 13:50:11 EDT
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.

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