- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Jan 2022 15:23:21 +0000
- To: public-webrtc-logs@w3.org
> By rejecting while the page is in the background we: > > * Clear some minuscule amount of memory sooner. > * Alert applications sooner to the fact that they will not, in fact, be getting mic/camera access. > > Admittedly, these are but minor benefits. Are there benefits to the inverse approach? I see two advantages: - Consistent cross-browser behavior - Reduce JS execution in backgrounded pages. Also, I do not see why we should be gentle to applications calling getUserMedia on backgrounded pages. Applications calling getUserMedia based on a user gesture should hopefully not end up into that issue. > Prevents unintended and surprising behavior which neither user nor application desire, like a previously inactive page asking for mic/camera permissions as soon as the user activates that page, a very long time after they had originally interacted with the page. For example, consider coming back from vacation on January and activating a tab for the first time in weeks. There are two different things: 1. rejecting the getUserMedia request: this can be done today based on a timer/heuristic without changing the spec. 2. rejecting the getUserMedia promise: this can only be done once the page gets focus as per spec. From what I see, 1 handles these concerns. It seems worth pointing out the issue you identified to help implementors, for instance as a note directly in the spec algorithm. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/846#issuecomment-1004165830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 3 January 2022 15:23:23 UTC