> Perhaps the renderer can tell the browser when it's playing a video ...

This would not quite work. The video-detector needs to know whether the video is actually visible on screen, because that is used as an indication that the user is active (and so if there are not activity on the input devices from the user, the screen would not auto-lock). If a video is playing in a background tab, or offscreen in the active tab, then that should not count as user-activity, and so the screen should auto-lock due to user-idleness. This is why the display compositor is the one that needs to provide this information to the window-server (and window server should notify that to the interested observers, e.g. the window-manager).

cc::CompositorFrameMetadata::may_contain_video was introduced [1] to help with this. It hasn't been plumbed through to ws/wm yet. That work needs to happen.

[1] https://codereview.chromium.org/2140783002

Does may_contain_video reflect whether the video is actually playing or not?
Maybe the long-term solution is going through the display compositor, but I believe in the short-term the renderer can tell the browser process whether it's playing a video or not. We can even run the same detection code in the renderer in order to preserve the current behaviour.

> Does may_contain_video reflect whether the video is actually playing or not?

The bit is turned on if a layer that may contain video is drawn (and not occluded, etc.) [1].

> Maybe the long-term solution is going through the display compositor, ..

Can you explain why it can't be a short-term solution too? Naively, it would involve plumbing the data from cc::Display through viz::MojoFrameSinkManager to ui::WindowServer (which is-a mojom::FrameSinkManagerClient). But I guess there are some complication here that makes it not suitable as a short-term solution?

[1] https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?sq=package:chromium&dr=CSs&l=914

This also needs to work with non-mus Chrome, so we can't assume there is a ui::WindowServer.

For browser, it would be FrameSinkManagerHost (which is-a mojom::FrameSinkManagerClient too), and then onto ash.

> The bit is turned on if a layer that may contain video is drawn (and not occluded, etc.) [1].

But what about the case that the video layer is drawn but the video is not actually playing? Imagine we have paused the video for example.

+apacible@. Maybe we want a better signal? 

Also keep in mind that the VideoDetector triggers today on more than just <video> tags: Flash (I know, I know), canvas/webgl animations, even CSS ones (poster circle).

Given that the VideoDetector signal is debounced, it could be meaningful to implement a DamageObserver API to DisplayCompositor and wire that back to the wm then ash? Not sure who would be responsible for the general "keep the screen on when a video/animation is playing" feature in the mus world.

I'll start looking into this to see how well may_contain_video works and hopefully start using it.