GNOME Bugzilla – Bug 593972
Interpret lid closed as confirmation of shutdown when not suspending
Last modified: 2021-06-14 18:22:03 UTC
If someone clicks shutdown and there are apps inhibiting shutdown we present a dialog asking for confirmation of the shutdown. However in cases where the user has disabled automatically suspending on lid-closed it can be dangerous for the user to close the lid while the confirmation dialog is being shown. One possibility is to interpret the lid closed even as confirmation of shutdown. Equivalent to clicking the "Shutdown anyway" button. However, perhaps we should only do this if the system isn't already configured to suspend on lid close. Though on the other hand, adding the complexity of handling that special case may not be worth it.
I'd like to point out that we prolly want to shutdown here as well even in the case where you suspend on lid close. If I explicitly select "Shutdown", it's b/c I expect to shutdown. I'd be disappointed to shutdown, shut the lid, travel somewhere, and then open the lid and realize my battery was low b/c I'd suspended.
Right - that is also what I meant by complexity - in the model of the action. There will be cases where this isn't desired but there is advantage to having the behavior be consistent, simple, and rational. We'll interpret the lid close as consent - or silent compliance. Now doing a shutdown + install updates may be an issue...
(In reply to comment #0) > If someone clicks shutdown and there are apps inhibiting shutdown we present a > dialog asking for confirmation of the shutdown. However in cases where the > user has disabled automatically suspending on lid-closed it can be dangerous > for the user to close the lid while the confirmation dialog is being shown. It's pretty trivial to add a notify::lid-is-closed action to gnome-session for this, but the real question is whether g-p-m in the running session thinks the session is active, or non-active. If it thinks the session is non-active, then this is a trivial fix as g-p-m will just ignore the lid event. If g-p-m thinks the session is active, then it will try to suspend instead of letting g-s shutdown, and they'll be a prize for who starts first. If the latter case is true, then either g-s has to poke gpm, or gpm has to check a property on g-s "is-trying-to-shutdown?" before it does the lid action. I don't mind which, but it depends on whether the session is active in the pre-shutdown-inhibit stage. (there's a bug in DeviceKit-power that makes notify::foo not work, I'll fix that now)
Is it perhaps reasonable to have gnome-session's shutdown dialog inhibit power management stuff, ensuring that other clients don't end / suspend the session until it has decided what to do?
As a user whose laptop has overheated a few times because I closed the lid before seeing the message, I concur that this is something that needs fixing. It is not only a problem with lid closing; assuming someone wants to shut down a stationary computer and leaves the room without checking the screen, the the computer would be running unexpectedly. One solution would be to have a timer, similar to the regular shutdown dialog, that defaults to “shutdown anyways” after 60 seconds.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.