

That might not be what users want either. In either case, it makes me question what the desired behavior should be. It's not clear to me whether Chrome muting the video here is a bug or a feature. Importantly, the call is still going I have to unlock my phone and leave the call or kill the Chrome app to terminate the call. When I unlock my phone, the video resumes. I also keep hearing the call on my phone (when I unmute my desktop). When I use Chrome for Android to connect w/appear.in to my desktop and then lock my phone, it's true the video freezes, but the audio keeps recording (I've muted the mic on desktop and I still hear audio being recorded by my phone's mic). Those results do not match what I see in Chrome (73 and 75) on my Samsung S8 (Android 9): Note: Chrome for Android behaves in expected way.īefore we move on this. The video stream(both camera and microphone) capture should stop immediately when phone is locked If there's a precedent, we may want to follow that. I've also pinged some DOM permission folks to see if this has come up before with other "powerful features" or features in Firefox where termination on phone lock is of consideration, or if this is a problem is unique to camera and microphone. We can then guide the android team to trigger this, either muting the tracks or revoking permission, respectively. I'm not aware of any spec language around this, so I suggest we look at Chrome, whether it mutes the tracks or fires the ended event (Firefox turns off the camera/mic devices & any hardware lights in either case). This privacy concern seems to trump any use case for this feature, and I agree the Chrome behavior seems desirable here. Doubly so when similar phone browsers work differently in this regard. That said, I agree it is not what most users would expect, and is therefore problematic, because users may accidentally record themselves when they think they are not. For instance, someone might specifically want this behavior to record a situation. I would say that the existing behavior is intended to the extent that no-one has thought about it as a problem before. Jan-Ivar is this something which needs to get fixed in the camera platform code or in the Fennec/Fenix frontend code? (In reply to Nils Ohlmeier from comment #2)
