GNOME Bugzilla – Bug 682420
Modal dialogs can block suspend
Last modified: 2012-08-31 22:23:20 UTC
Going home from the office, I closed the lid, yanked my laptop out from the dock, and stuck it in my bag. When I got home, it was exceedingly hot. Opening up, it smelled of burnt plastic (don't worry, no serious damage to the computer as far as I can tell). The screen told all. A modal dialog asking me to emit the wireless password to the Red Hat Wireless network had come up. Dismissing it made the computer suspend as normal.
Oh. Note that the modal dialog appeared *above* the screen shield. I didn't really care about that, but that's another bug.
Uhm... in what way a modal dialog can block suspend? I would have understood in the 3.4 days, when it prevented gnome-screensaver to lock, and thus g-s-d would not continue to upower, but now...
There might be a grab that g-s-d has to take?
This happened again yesterday/today. After waking up from hibernate (the battery died), I noticed the same scenario. Parts of the construction of my laptop were destroyed. This is very critical.
I tried to reproduce this with a bare sleep 20; gdbus call --system --dest org.freedesktop.UPower --object-path /org/freedesktop/UPower --method org.freedesktop.UPower.Suspend and both network and PolicyKit dialogs were not able to prevent suspend: the curtain would fall behind the dialog and suspend would continue as usual. Similar results happened with the power plugin. My testing, which had bug 668703 applied, happened with sleep-inactive-ac 20 and a manually invoking gnome-screensaver-command --lock (session must be already IDLE/locked, otherwise sleep-inactive timeouts are ignored) and pkexec bash. Having the polkit dialog before the screen lock or after it did not influence the results, and the screen was properly locked after 20 seconds of inactivity. I did not test without bug 668703, as I'm assuming the patch there will be pushed soon. Two notes from testing: - Activating the screen lock when suspending is not necessary, as upower will do it through logind - ScreenShield.lock() is not idempotent as thought: the curtain falls again.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 680689 ***
How is this a duplicate?
Oh, whoops, it is. Stupid bugmail made me think you marked this as a duplicate of another bug. *** This bug has been marked as a duplicate of bug 680689 ***
*** Bug 683139 has been marked as a duplicate of this bug. ***