** Changed in: gnome-session (Ubuntu)
Importance: Undecided => Low
--
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:
New
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 : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
