Screen doesn't lock or go to sleep when certain Chrome tabs are open

[Julian J. M.]

$ 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.

[zajc (zajcek)]

I have exactly the same problem on Ubuntu 16.04. If Google Chrome is running and toggl, twitter, or gmail tab is opened than the screen lock doesn't work. The only workaround is to press CTRL-ALT-L or close Google Chrome.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Hooman (hooman67)]

I have a similar issue when I have a Slack (https://slack.com/) page open in Chrome with desktop notifications enabled, on Ubuntu 17.04

[Hooman (hooman67)]

Also, I think this is a critical bug, because lock screen is essential in keeping users safe, when they leave their computers unattended. I think the importance of this bug should not be Low.

[Roberto (br70)]

I happens to me as well.

Running:
$ google-chrome --version
Google Chrome 62.0.3202.62

on:
$ lsb_release -rd
Description: Linux Mint 18.1 Serena
Release: 18.1
$ uname -a
Linux NATT3600 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Have to close Chrome or press the lock screen shortcut.

[Adam (adlid)]

Just ran into this today also and found a solution. If you run `dbus-monitor --session`, then relaunch Chrome, you'll see it is inhibiting sleep:

method call time=1509049627.133691 sender=:1.260 -> destination=org.freedesktop.PowerManagement serial=3 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=Inhibit
   string "/usr/bin/google-chrome-stable"
   string "WebRTC has active PeerConnections"

The final line above gives the clue to why this is occurring: a tab has opened a WebRTC connection and Chrome thinks this is something interactive that needs to prevent screen lock/sleep. To see which tab or tabs are the culprits, go to chrome://webrtc-internals/ and you should see each connection listed.

If you close the tabs with WebRTC connections, in the dbus-monitor session you'll then see Chrome release the Inhibit and the screen will lock after the usual timeout:

method call time=1509049693.689398 sender=:1.260 -> destination=org.freedesktop.PowerManagement serial=4 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=UnInhibit

[Evan Carroll (evancarroll)]

Just found this, still having this bug -- with Reuters.

https://unix.stackexchange.com/q/451413/3285

[Deno (farmerhelpx)]

This is why linux will never work. 2 years and no solutions for this.

And all you morons can say is "read the documentation"

We are not programmers, and never will be.

[Tim Richardson (tim-richardson)]

uBlock fixes it for me and others ... But there should be some user control

[Daniel Nilsson (daniel-dnil)]

Hi,

This issue has been bugging me for some time, in my case it was enough to simply have a Dropbox tab open in chrome:

lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04

method call time=1534068740.331221 sender=:1.134 -> destination=org.freedesktop.PowerManagement serial=3 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=Inhibit
   string "/usr/bin/google-chrome-stable"
   string "Uploading data to bolt.dropbox.com"

This bug is towards gnome-session, which I'm not sure is the issue here. I'm using the XFCE desktop, and have this issue so is it really related to gnome-session? Seems like a bug in chrome, but I can't find any bugreport towards chrome on this. Does it exist? Seems like a pretty severe issue to me, my office desktop is on 24/7 and I rely on the screeensaver to power off monitors when I'm away.

[CarbonPepper (carbonpepper)]

Brand new 18.04.1 build and I'm seeing this behaviour. It would be preferable to have a gui power control which allows the user to override inhibit behaviour on a system-wide basis.

[CitizenKlaw (joelpomales)]

This happens to me on various recent distros I've had (Ubuntu 18.04, Pop!_OS). It happens to me on a site that I use for work (https://www.servicenow.com) which is the one I use daily and develop for.

If I leave any tab open for the platform, it will not lock. I've seen this behavior with Chrome, Chromium, Vivaldi and Opera. I guess since they use the same web engine.

Big security risk. Firefox is not affected, but I am really missing some features in Chrome/Chromium that Firefox cannot give me (one, in particular. But still...).

[Travisgevans (travisgevans)]

I just discovered this the hard way. I happened to have speedtest.net opened in an unfocused Chromium tab on an inactive workspace and spent quite a bit of time going through a wild goose chase trying to figure out why my previously reliable DPMS/screen-locking setup suddenly flat-out refused to work at all. This was just running in the i3 window manager; no Gnome or KDE, nothing fancy. Closing the tab involved, or Chromium altogether, makes it work again.

The closest upstream bug I could find is https://bugs.chromium.org/p/chromium/issues/detail?id=654659 , but it appears to have been basically ignored by the developers.

It seems that Chromium has issues with inhibiting power management too aggressively. So aggressively I'd almost call it abusive.

[W-barath-hotmail (w-barath-hotmail)]

This bug has been around since 14.04 and persists in 18.04

This bug causes unexpected filesystem corruption
 - hit the power button to suspend the laptop and put it in your suitcase. Take a flight and find it dead and corrupt on arrival.

This bug causes lost work
  - Suspend the laptop, suspend fails, work you didn't save is lost because the system unexpectedly loses power.

This bug causes permanent degradation of laptop batteries
 - Power policy set to power off at 20% capacity to extend laptop battery. Fails, battery is drained until it is flat, resulting in permanent damage and reduced capacity.

This bug causes security violations
 - Suspend the laptop. Suspend never happens. Someone else comes and uses it because it never locked even though you hit the button.

These are serious issues.

The policy should be terminated immediately. Its purpose was to prevent lost work. Instead, it is causing lost work, lost hardware stability, lost security.

[ethanbrown (ethandbrown)]

I agree with W-barath-hotmail that this is a serious problem that needs to be addressed. I believe on some occasions suspend fails even after I've killed Chrome.

Please increase the Importance ranking of this bug.

[Tim Richardson (tim-richardson)]

I have noticed that
a) systemctl suspend
does actually suspend, but it takes about 30 seconds.
I'm on 18.04.1 with kernel 4.18.0-13-generic from the proposed PPA
This is quite surprising, but good news. I don't know why this is working
now. It works with either Chromium or Chrome open, with hangouts running.
Because gnome uses systemctl suspend, this means that manual suspend from
gnome shell is also working.
I just suspended right now with a hangouts conversation in progress and a
Zoom meeting started, and it succeeded.

Maybe the more recent kernel fixes it?

b)
pkexec systemctl -i suspend
(run with root privileges)

always works, but this is less suprising, since -i means ignore inhibitors.

On Thu, 13 Dec 2018 at 12:16, ethanbrown <email address hidden> wrote:

> I agree with W-barath-hotmail that this is a serious problem that needs
> to be addressed. I believe on some occasions suspend fails even after
> I've killed Chrome.
>
> Please increase the Importance ranking of this bug.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1600622
>
> Title:
> Screen doesn't lock or go to sleep when certain Chrome tabs are open
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions
>

--
Tim Richardson

[Jeremy Walker (machineghost)]

The importance on this ticket is incorrect: it should not be marked "low". According to https://dev.launchpad.net/BugTriage#importance) "Low" is defined as "legitimate but that is not scheduled for Canonical staff to fix in the next 6 months."

This is a MAJOR issue. As W-barath-hotmail noted it can cause some extremely serious side effects for anyone who relies on power management. As such, this ticket should have an importance of "High" ("we believe we will work on in the next six months"). To ignore it for six or more months would be to deliberately cause serious user damage.

Also, this bug is difficult for users to track down. It's not like problematic tabs flash red or something, so each user has to figure out on their own that not only is Chrome the source of the problem, but a specific tab within Chrome. As a result, the number of users affected by this bug is undoubtedly much higher than what's reflected on this page, as many affected users just aren't able to track the problem to this page.

[Tim Richardson (tim-richardson)]

If you have this bug, what is the result of opening a terminal, and running
systemctl suspend
and waiting for a minute?

On Fri, 14 Dec 2018 at 08:24, Jeremy Walker <email address hidden>
wrote:

> The importance on this ticket is incorrect: it should not be marked
> "low". According to https://dev.launchpad.net/BugTriage#importance)
> "Low" is defined as "legitimate but that is not scheduled for Canonical
> staff to fix in the next 6 months."
>
> This is a MAJOR issue. As W-barath-hotmail noted it can cause some
> extremely serious side effects for anyone who relies on power
> management. As such, this ticket should have an importance of "High"
> ("we believe we will work on in the next six months"). To ignore it for
> six or more months would be to deliberately cause serious user damage.
>
> Also, this bug is difficult for users to track down. It's not like
> problematic tabs flash red or something, so each user has to figure out
> on their own that not only is Chrome the source of the problem, but a
> specific tab within Chrome. As a result, the number of users affected by
> this bug is undoubtedly much higher than what's reflected on this page,
> as many affected users just aren't able to track the problem to this
> page.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1600622
>
> Title:
> Screen doesn't lock or go to sleep when certain Chrome tabs are open
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions
>

--
Tim Richardson

[Tim Richardson (tim-richardson)]

I switched to KDE to have a look at it, by installing KDE Neon from the PPAs. Otherwise the same environment. The slow suspend doesn't happen in plasma, it suspends in five seconds, while still suspending properly (including open VMWare virtual machines). So it's not simply Chrome, the bug needs gnome as well.

[Jeremy Walker (machineghost)]

>If you have this bug, what is the result of opening a terminal, and running
>systemctl suspend and waiting for a minute?

Nothing happened for a few seconds, then my network turned off, then both screens turned off. I thought I was screwed, because my computer has never come back to life from a "suspend" before, but when I pressed some keys it (slowly) came back to normal.

So, it would seem that the command you provided (and I guess system suspension in general) is working just fine ... despite my system being in a state where my screens wouldn't turn off for power saving after five minutes, as they normally would.

[Brent Gardner (mongo02)]

While this could be considered an OS-related bug (to deny apps from being able to prevent power saving mode), I searched for bugs/features in Chromium. I suggested a new Chromium switch/feature in a related bug: https://bugs.chromium.org/p/chromium/issues/detail?id=257511#c73

[Brent Gardner (mongo02)]

Submitted a new Chromium bug/feature request (ignore comment #22 above): https://bugs.chromium.org/p/chromium/issues/detail?id=931235

[Sebastien Bacher (seb128)]

Could those having the issue give details on the webpage that create the issue? Having videos and such blocking lock/suspend is a feature not a bug...

[Sig Bee (sloppysphincter)]

>>>>Could those having the issue give details on the webpage that create the issue?

Here
https://unix.stackexchange.com/questions/451413/disabling-chromium-xfce-power-management-inhibition
it is
https://www.reuters.com/article/us-usa-immigration-children-idUSKBN0EK1VM20140609

Here
https://askubuntu.com/questions/1051688/how-to-stop-chrome-from-making-suspend-inhibits
it is
https://www.theage.com.au/

it just went and closed my Opera tabs one by one, and for me it was
https://ipleak.net/

[Misha Nasledov (mishan)]

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.

[Sebastien Bacher (seb128)]

@Misha, thanks for your detailled comment.

> it exposes an obvious weakness that should be resolved in the GNOME end as well

what do you mean there? GNOME can't really control what websites are doing, if chrome(ium) has the issue and not firefox it suggests it's possible to get it right and the issue is rather on the Google webbrowsers side.

Also the browser could make it obvious and e.g display an icon on the tabs, the same way they do it for indicating that a tab is playing sound

[kinghat (kinghat)]

ive had this issue for years. happens on win 10, ubuntu and kde neon. i either have to close or minimize all chrome windows. no issue from firefox. i posted the bug years ago to chrome but no idea where that went.

[John Ottenhoff (ottenhoffj)]

This is still an issue!

It is also more important than "low".

We need to have a way to secure desktops when users forget to log out when stepping away.

[Pierre Gallaz (pierregallaz)]

It's been an issue for several years, across several ubuntu versions, it has potential critical consequences in some cases, yet it is "low" and "unassigned". I think there are valid reasons to make it a priority. Someone commented that installing the ublock extension fixed the issue, has anyone tried? I'm trying now, and will let you know.

[pepster (jheled)]

Still a problem for me (Kubuntu 19.04), even with uBlock installed.

[W-barath-hotmail (w-barath-hotmail)]

This bug is 5 years old, and really, it should be a release-blocking bug.

How much more severe can a bug be than causing physical damage, bypassing security, corrupting the filesystem, and causing users to lose work?

It's difficult to believe that Canonical has a competent release manager if they're ignoring this for 5 years.

[Tim Richardson (tim-richardson)]

I haven't had this problem for several releases, so it is only triggered under some circumstances. I suspected the hangouts extension (which I no longer use)

[Petter Sundlöf (petter-sundlof)]

Confirmed on Ubuntu 19.10 and Chrome 78. Screen blanking initiaties when Chrome isn't running, but never does when I have it active.

[Dmitry Diskin (diskin)]

Why is it still "Low Importance"?

[Blue (vali-dragnuta)]

My 2c, no website should ever be able to dictate if my monitor goes or not to standby. More to the point, I think the screen locking is also disabled and this makes it a potential security issue, as it would be trivial for any external party to weaken the security profile applied by the user. Just as we control how we must explicitly allow websites to grab audio, or video, we should also explicitly control if it can override other system settings. Or, there should be something similar with how macos or android grants some permissions on a per-app basis.

[Sebastien Bacher (seb128)]

You maybe would have more change upstream if you reported it on https://gitlab.gnome.org/GNOME/gnome-session/issues

The system could prompt to ask if you allow the application to inhibit the screen locking and suspend, but in practice you would probably want to grant that permission for your webbrowser for e.g being able to play a youtube or netfix video without interuption. It could prompt by website but then it becomes tedious, do you really want to get asked that question on regular basis by random websites you browse?

In short there is no obvious clean solution

[CarbonPepper (carbonpepper)]

Still a problem in 20.04.

The people with the power to change this never experience the pain of it. Too many Devs don't use power management themselves, they have desktop machines and leave them running 24/7.

I wish leadership would drive another 100 papercuts project.