This bug has been driving me crazy for a while. I've spent a lot of my
time investigating it. I don't use laptops much, so the primary issue I
run into is that none of my screens go into suspend, so sometimes I'll
find all my screens were on for hours without me realizing it. This
wastes a lot of power and is not good for my screens.

There are definitely certain sites that are more aggressive than others.

HomeDepot.com is one that'll open WebRTC workers that will inhibit PM,
even with the latest Chromium WebRTC PM policy changes.

Facebook may or may not inhibit power management -- it depends on what
is displayed in the tab and (fortunately) whether the tab is in the
foreground or background of the Chrome/Chromium window. However, it
often does not care if you are on a different desktop. Videos and
animated GIFs are two of the major culprits.

Sometimes Google Hangouts on the GMail page decides to launch some
WebRTC stuff and totally inhibit PM as well. The only fix for this is to
just close the tab -- for WebRTC it doesn't seem to matter if it's in
the foreground or not.

I can go on, but it's lame that web developers are so easily able to
screw with our power management. And I guarantee you that this is not
something that is typically tested in web development. I don't believe
Firefox has these issues.

The funny thing is that, years ago, I did wish web browsers inhibited
the screensaver while I was watching videos. Now they've gone way too
far. Without the "Inhibit" applet showing me a red "X", I have no idea
if my screens are going to go to sleep or not. I often just run `xset
dpms force suspend && cinnamon-screensaver-command -l` when walking away
to be safe.

One solution that kind of sucks but works 100% of the time is just to
killall chrome before walking away. You'll have to go through and
restore all your windows, but at least it's something.

Something to simply block an application from inhibiting power
management would be a nice first step. If it were a panel applet or
something, one could easily re-enable power management inhibition for
watching videos.

I think that Chromium needs to do better, but I think that it exposes an
obvious weakness that should be resolved in the GNOME end as well.

-- 
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     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to