Bug 200511 – Muted <video> elements can block display from sleeping.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

Muted <video> elements can block display from sleeping.

[Radar WebKit Bug Importer]

<rdar://problem/54043061>

[Jer Noble]

Created attachment 375724 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 375724 [details]
Patch

Clearing flags on attachment: 375724

Committed r248387: <https://trac.webkit.org/changeset/248387>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

This sounds like it was correct behavior. When I'm watching a video, the display should not sleep. Whether I decided to mute audio is irrelevant.

[Jer Noble]

(In reply to Alexey Proskuryakov from comment #5)
> This sounds like it was correct behavior. When I'm watching a video, the
> display should not sleep. Whether I decided to mute audio is irrelevant.

It most definitely was not correct.  We have no concept of whether the user is "watching" a video. You might make the argument that a video that started out not-muted and was muted with a user gesture should not cause the display from sleeping, but we would also have to add "is the video visible in the viewport" to that requirement, to keep a user-muted video which was scrolled offscreen from keeping the display awake.

[Jon Lee]

Do we treat a muted video and the whole system sound muted the same?

[Alexey Proskuryakov]

> It most definitely was not correct.  We have no concept of whether the user is "watching" a video.

If we have no such concept, then we must assume that the user is watching it.

My understanding is that after this change, any video that I'm watching muted (like a Netflix or YouTube video, whether windowed of fullscreen) will eventually go dark. That's obviously an incorrect behavior.

And there are tons of reasons why one may not want sound.

[Jer Noble]

(In reply to Alexey Proskuryakov from comment #8)
> > It most definitely was not correct.  We have no concept of whether the user is "watching" a video.
> 
> If we have no such concept, then we must assume that the user is watching it.

No, that's absolutely not true. When trading off a very narrow use case vs. the potential to completely drain the users' battery, we must /not/ assume that the user is watching it.

[Alexey Proskuryakov]

You are saying that muting is a narrow use case. That is equivalent to claiming that every video player in the world is wrong, as they give this functionality a prominent spot in their UI. They must have found that their users want that and use that! It could be that you are right, and everyone else is wrong, but you would need much better evidence for that than strong words.

I agree that there may be an opportunity to further improve battery life if we can identify unwanted videos that play like this and drain the battery. The current patch doesn't implement any insightful heuristics, and outright breaking muted playback is clearly unacceptable in my opinion.

As it stands now, is there any benefit in keeping the patch in the tree?

[Jer Noble]

(In reply to Alexey Proskuryakov from comment #10)
> You are saying that muting is a narrow use case. That is equivalent to
> claiming that every video player in the world is wrong, as they give this
> functionality a prominent spot in their UI.

And you assume that users who mute a video want the display to remain on, regardless of whether they're actually watching or listening to it.  In fact, muting a video is a strong signal that users aren't actually watching it.

> As it stands now, is there any benefit in keeping the patch in the tree?

Yes. It protects users from having autoplaying muted videos from draining their battery.