Closed Bug 1434601 Opened 5 years ago Closed 2 years ago

Screen saver kicks in during WebRTC call

Categories

(Core :: WebRTC, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
relnote-firefox --- 78+
firefox78 --- fixed

People

(Reporter: jya, Assigned: jib)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [wfh])

Attachments

(1 file)

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.
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.
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?
Rank: 25
Priority: -- → P3
Summary: Screen saver kicks in during hang-out call → Screen saver kicks in during Hangout call
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.
(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.
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.
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)
Also: https://www.w3.org/TR/wake-lock/, though not implemented by anyone yet.
Duplicate of this bug: 1444337
Summary: Screen saver kicks in during Hangout call → Screen saver kicks in during WebRTC call
Blocks: hangouts
Screen saver never kicked in on my more then hour call today.
Duplicate of this bug: 1520332

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.

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

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?

Duplicate of this bug: 1634043
Priority: P3 → P2
Whiteboard: [wfh]

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

Assignee: nobody → jib
Pushed by jbruaroey@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
QA Whiteboard: [qa-78b-p2]
Blocks: wakelock
You need to log in before you can comment on or make changes to this bug.