gnome-shell does have some support for inhibitors, but it is in the logout/shutdown/reboot dialog, which doesn’t easily apply to suspend.
It’s not just that there isn’t a dialog in that case, but also that “list existing inhibitors before user confirms the action” is quite different from “try to perform action, figure whether it was because of inhibitors if it failed, show some kind of feedback”.
Then there is the issue that there are various ways of triggering suspend, and not all of them go through gnome-shell (power button, lid close, …).
Maybe gnome-session itself could show a notification in that case? That would at least catch all callers that go through the org.gnome.SessionManager API (and those that use logind directly won’t respect the inhibitors anyway).
firefox for some reason thinking it’s playing video
I wonder why it inhibits suspend for media playback? Is it to keep playing when closing a laptop lid?
It is expected that most apps inhibit “idle” (that is, automatic screen lock and suspend after user inactivity). As far as I know, inhibiting suspend should be limited to actions that could result in actual breakage when interrupted (like applying system updates or burning a CDR (yes, that old!))
Right. The browser should definitely only inhibit idle, not suspend. Inhibiting suspend for video playback is surely wrong, because inhibiting idle is sufficient to prevent the system from suspending on its own after the idle timeout, so it won’t suspend itself when the user is watching a video, which is what the browser is trying to accomplish. Additionally inhibiting suspend just prevents the user from manually triggering suspend which is surely not desired in this case; that’s going to result in user closing the lid expecting suspend and then being surprised when the battery runs out. I knew that Chrome had this problem, but I’m surprised to learn that Firefox does too. I agree with Florian: use suspend inhibitors primarily for situations where suspend would be destructive.
But anyway, to actually answer your question: since systemd 257, suspend inhibitors are now strong by default rather than weak. So previously, they were usually just ignored, and so nobody noticed that they didn’t work well in GNOME. Now that they are actually respected, users are finally noticing they don’t work well. If you follow the link Sebastian posted, you’ll see that Adrian has recently been trying to improve this…
I think what Firefox started doing recently is inhibit suspend for audio playback to allow playing music while not actively using the computer and still blank the screen.
Same, was trying to figure out for a while why suspend doesn’t work sometimes. Turns out it was brave playing a video. Definitely think it should show a popup with a list of inhibitors when you suspend via the suspend button. Thought for the longest time that suspend just didn’t work right on my system
Simple answer a desktop needs to be friendly at most. You don’t want a notification saying “inhibitor is blocking suspend” cause not all of us knows wth is inhibitor
Of course. A notification would say something like “Firefox is blocking suspend”. It could maybe also include the reason that the app provided, although in a quick test Firefox takes two inhibitors (“Playing video” and “Playing audio”).
Same difference. gnome-session takes a logind inhibitor whenever an app requests for an action to be inhibited (as long as that action is relevant to logind, that is…)
