Closed Bug 1434601 Opened 5 years ago Closed 2 years ago
Screen saver kicks in during Web
47 bytes, text/x-phabricator-request
|Details | Review|
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?
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.
Summary: Screen saver kicks in during Hangout call → Screen saver kicks in during WebRTC call
Screen saver never kicked in on my more then hour call today.
Assignee: nobody → jib
Pushed by email@example.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
You need to log in before you can comment on or make changes to this bug.