Why is it still "Low Importance"? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1600622
Title: Screen doesn't lock or go to sleep when certain Chrome tabs are open Status in gnome-session package in Ubuntu: Confirmed Bug description: $ lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 $ apt-cache policy gnome-session-bin gnome-session-bin: Installed: 3.18.1.2-1ubuntu1.16.04.1 Candidate: 3.18.1.2-1ubuntu1.16.04.1 Version table: *** 3.18.1.2-1ubuntu1.16.04.1 500 500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.18.1.2-1ubuntu1 500 500 http://es.archive.ubuntu.com/ubuntu xenial/main amd64 Packages I'm using gnome-session-flashback What happens: The screen doesn't lock when having certain pages in Chrome tabs Expected: The screen should lock after the configured timeout in settings. I've been having this issue sice before 14.04, which I recently upgraded (fresh install) to 16.04. After fresh install, the screen would turn down and lock the computer after 10 minutes (or whatever time I setup). At one point it stopped working. The screen never shuts down unless I manually lock the session with CTRL-ALT-L. I've followed the steps in https://wiki.ubuntu.com/DebuggingScreenLocking#Debugging_procedure The culprit seems to be that Chrome issues some suspend inhibitions through dbus when doing certain operations. Many people find this problem when using Yahoo Mail. I can reproduce it with Odoo. I'm pretty sure that Chrome is doing something else of what i've found out. 1) Gnome screen saver works correctly. I can trigger it manually with: $ gnome-screensaver-command -a 2) Gnome screen saver never receives the "session idle" status callback. 3) When Chrome is not running, I can manually inhibit the idle status: $ gnome-session-inhibit --app-id test --reason "manual idle inhibit" --inhibit-only --inhibit idle:suspend Inhibiting until Ctrl+C is pressed... 4) I can query the inhibitors: $ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.GetInhibitorsmethod return time=1468170482.066533 sender=:1.19 -> destination=:1.1315311 serial=1329103 reply_serial=2 array [ object path "/org/gnome/SessionManager/Inhibitor1686" ] $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetAppId ('test',) $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetReason ('manual idle inhibit',) $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetFlags (uint32 12,) 12=4(suspend) + 8(idle) 5) When testing, I can inhibit for 70 seconds, idle timeout being 60 (1 minute). After these 70 seconds pass, the screen locks. 6) Regarding Chrome, this is the information I get when querying the inhibitor: GetAppId: ('/usr/bin/google-chrome-stable',) GetReason: ('Uploading data to 10.200.0.163',) GetFlags: (uint32 4,) The flags just inhibits suspend, not locking or entering powersaving mode. This inhibitor seems to stay for 10-15 seconds, then goes away for another 30-60 seconds. The screen NEVER locks when this tab is open. No matter the inhibitor is present or not. I'm not sure where to go on. If it's a Chrome bug it must be using other mechanisms to prevent the idle timeout. Any ideas on what to look for? Julian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp