#CBC-RS/TC-watchlist

So sure, right after I file the bug both CBs go to sleep. More testing ....CB will not sleep when:

1. the chat is opened ie.not just the conversation list 
2. the chat is active ie. comments are made within the 7 minute suspend time
3. notifications are on

The CB will sleep:

1. chat is opened  
2. chat is inactive for longer than 7 minutes
3. notifications are off

Thanks for filing dymphep@

Hangouts can can lock things to prevent screen-off when doing a video chat. It shouldn't be doing it otherwise though. 

Did you happen to do video chat before this happened?

Please file a feedback report via Alt-Shift-i after seeing the issue. file:///var/log/power_manager/powerd.LATEST (included in the report) will have an explanation of why the system didn't go to sleep.

And in case it's related, it looks like you have an earlier feedback report at https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReport=10228924295 ("Dev channel Asus Flip will not sleep while connected to the charger with only a new tab open.").

In that case, it looks like the system wasn't suspending due to DesktopCaptureDevice being active:

[0615/181519:INFO:daemon.cc(1430)] Received updated external policy: ac_dim=0s ac_screen_off=0s ac_lock=0s ac_idle_warn=0s ac_idle=30m battery_dim=0s battery_screen_off=0s battery_lock=0s battery_idle_warn=0s battery_idle=10m ac_idle=no-op battery_idle=no-op lid_closed=suspend use_audio=1 use_video=1 presentation_factor=2.0 user_activity_factor=2.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs, DesktopCaptureDevice is running)

I think that this is used by Cast, and perhaps also by apps that are using WebRTC to capture video or audio.

Feedback sent 7:15 EDT

 Issue#622430  Feedback - CB did not enter sleep mode

No video calls made today, no new messages in 2 chats open in hangouts.google.com between 6:52 and 7:07pm

Open tabs:
Chrome OS new tab
bugs.chromium.org
hangouts.google.com open as a second window

Sent 8:18pm EDT

 Issue#622430  - second feedback this time on battery

The file:///var/log/power_manager/powerd.LATEST does not change for the next 20 minutes between the last user activity
[0624/194206:INFO:daemon.cc(1385)] Saw user activity
and the next user activity
[0624/200408:INFO:daemon.cc(1385)] Saw user activity

I reset the browser settings > shutdown and restarted. Feedback 9:12pm EDT

This time CB did supsend.

[0624/204314:INFO:suspend_delay_controller.cc(139)] Announcing suspend request 50003969 with 2 pending delay(s) and 0 outstanding delay(s) from previous request
[0624/204314:INFO:suspend_delay_controller.cc(88)] Got notification that delay 50003970 (shill) is ready for suspend request 50003969 from :1.11
[0624/204314:INFO:daemon.cc(1405)] Chrome is using normal display mode
[0624/204314:INFO:suspend_delay_controller.cc(88)] Got notification that delay 50003969 (chrome) is ready for suspend request 50003969 from :1.7
[0624/204314:INFO:suspend_delay_controller.cc(224)] Notifying observers that suspend is ready
[0624/204314:INFO:suspender.cc(466)] Starting suspend

Thanks! The log is long enough that the beginning of it isn't included in the feedback report, but the usual 7-minutes-to-dim delay while on AC was doubled to 14 minutes, presumably due either to user activity being observed soon after the screen dimmed or turned off earlier (a signal that the delay was too short) to an external display being connected. See https://www.chromium.org/chromium-os/packages/power_manager/inactivity-delays for more details about how this works.

In the second feedback report (http://feedback/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:dymphep&lReport=10603681211), there's intermittent video activity that kept the system from suspending the screen (and also occasional audio activity): 

[0624/194750:INFO:daemon.cc(1369)] Saw normal video activity
...
[0624/195621:INFO:daemon.cc(785)] Audio is active
...
[0624/195622:INFO:daemon.cc(1369)] Saw normal video activity
...
[0624/195632:INFO:daemon.cc(785)] Audio is inactive
...
[0624/195729:INFO:daemon.cc(1369)] Saw normal video activity
...
[0624/195752:INFO:daemon.cc(785)] Audio is active
...
[0624/195802:INFO:daemon.cc(785)] Audio is inactive
...
[0624/200249:INFO:daemon.cc(1369)] Saw normal video activity

This looks to me like it's working as expected from the power manager's perspective. I think that hangouts.google.com occasionally fades from one background image to another, and I suspect that this is being interpreted as video activity. As such, I think that this is a duplicate of  issue 590311 ... which is conveniently assigned to me. :-P I have a proposed fix for it sitting around, so I'll dust it off and do some testing to see if I can reproduce this issue with Hangouts open and check if my change fixes it.

Regarding comment #9

Would an animated GIF trigger the intermittent audio/video activity? I wonder if the existence of a GIF in a Hangout would cause this issue.

#10: It would only register as video activity if it's 320x240 or larger, has a high framerate, and is continuously looping.

Pretty sure I provided the offending .gif in the hangout. It's larger than 320x240, high framerate and looping nonstop. 

I turned off notification sound for two extensions. Checker plus for Gmail and Calendar. 

There are no more INFO:daemon.cc(785)] Audio is active.

The CB suspended with Hangouts open. Copied part of the var log in this Doc.
https://docs.google.com/document/d/1Z1gpmt4taiFrwW5N79e6bxnWuLQZAbMElyfQU3jypRc/edit?usp=sharing

Yes, I think it's unfortunately easy for apps and extensions to accidentally leave audio streams open. :-( See  issue 454830  (chrome://media-internals lists the responsible tabs) and  issue 365869  for some more discussion that didn't go anywhere.