1434601 - Screen saver kicks in during WebRTC call

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Jean-Yves Avenard [:jya]]

My screen is set to turn off after 5 minutes of inactivity.

During a hangout call, the screen saver will activate every 5 minutes; requiring password to be entered etc..

During a WebRTC call, screen saver should be deactivated.

Comment 1

[Eric Rescorla (:ekr)]

This seems pretty invasive and potentially violates POLA in a way that negatively impacts user security. Specifically, it allows a site which has camera/mic access to deactivate my screen saver! Does any other browser do this.

Comment 2

[Nils Ohlmeier [:drno]]

Sounds like jya is not asking to give site an API to deactivate the screen saver, but that the browser should do it generically. 

But with that we then turn into the territory of what is a "WebRTC call"? A PeerConnection with just a data channel? How about a PeerConnection where you only receive audio and/or video? PeerConnection which send audio/video?

While I have noticed the same annoying behavior in Hangouts I can't recall that the same ever happened to me on appear.in calls. So maybe the Hangout folks are not doing something other WebRTC calling services do?

Comment 3

[Jean-Yves Avenard [:jya]]

This only occurs with hangout from what I can tell. With appear.in it works as expected.

As :drno mentioned, this is a usability issue. You're in the middle of a call and suddenly your screen turns off: how is that for user experience?

Just like with normal media playback, or anything where one can assume the user is in front of the screen, the screen saver should be disabled. There is user input, it just happens to not be in the form of a keypress or mouse movement.

In a hangout session using Chrome, the screen saver will not kick in, resulting in an enjoyable experience. Or at least not an unexpected one.

Comment 4

[Nils Ohlmeier [:drno]]

(In reply to Jean-Yves Avenard [:jya] from comment #3)
> This only occurs with hangout from what I can tell. With appear.in it works
> as expected.
>
...
> 
> In a hangout session using Chrome, the screen saver will not kick in,
> resulting in an enjoyable experience. Or at least not an unexpected one.

I just tested this:
- in an appear.in call on Firefox the screen saver never kicks in even if I don't touch the keyboard for 3 times as long as my screen saver timeout.
- in a Hangouts call in Firefox the screen saver kicks in pretty much at the timeout value
- in a Hangouts call on Chrome the screen saver does not kick in

I think this clearly speaks to the fact that the Hangouts developers don't know how to prevent the screen saver from kicking in on Firefox. But the appear.in developers know how to accomplish that.

So nothing to fix on our end. Something the Google folks need to fix on their end.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

It's common when playing videos on phones, for example, for screen lock to be disabled.  This includes both apps, and also playing videos in a browser.

This is managed through the HTMLVideoElement and it's use of the WakeLock (see ::UpdateScreenWakeLock(), and perhaps more interesteringly HTMLMediaElement::WakeLockBoolWrapper::UpdateWakeLock()).  When paused *or* muted, the lock is released. Perhaps all the video elements are muted *at the mediaelement level*, while in appear.in they aren't but are muted in some other way, or have the audio track replaced with a silent one, etc.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

And I didn't mean to imply just on phones; this is normal behavior (and I presume in Chrome as well, though perhaps the details are different)

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Also: https://www.w3.org/TR/wake-lock/, though not implemented by anyone yet.

Comment 9

[Nils Ohlmeier [:drno]]

Screen saver never kicked in on my more then hour call today.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

See also bug 1520332 comment #3; the media element involved in rendering a hangouts call doesn't have an audio stream, so our logic to deactivate the screensaver doesn't fire.

Comment 12

[Jean-Yves Avenard [:jya]]

(In reply to Chris Pearce [:cpearce (GMT+13)] from comment #11)

See also bug 1520332 comment #3; the media element involved in rendering a hangouts call doesn't have an audio stream, so our logic to deactivate the screensaver doesn't fire.

The logic is rather puzzling; So with audio you can see the video, but not without? If it didn't have a video stream, sure.

Comment 13

[Paul Adenot (:padenot)]

This is probably to not inhibit the screen saver when having a web page open that has lots of "gifs" that are in fact looping videos.

How about extending this logic to inhibit the screen saver also if there is a video playing and also the page is also playing audio?

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Suggest we move on this and implement the comment 13 suggestion.

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Bug 1434601 - Do screen wakelock even without audio if video element is sourced by a media stream.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9881a50bded4
Do screen wakelock even without audio if video element is sourced by a media stream. r=alwu

Comment 18

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/9881a50bded4