- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Dec 2019 02:30:14 +0000
- To: public-webrtc-logs@w3.org
To clarify, https://github.com/w3c/mediacapture-main/pull/644 doesn't actually remove in-content selection, it removes 1 of 3 decision makers:
1. application
2. ~user agent~
3. user
The _application_ still has full control. Only when it is indecisive, instead or "browser chooses" we'd say "user picks". This removes implementation dependency, improving web compat.
In-content selection would continue to work on browsers that grant all devices. But browsers would also be required to implement a picker when constraints don't reduce to 1 choice (<5% of users?)
Why? Firefox might drop labels to satisfy https://github.com/w3c/mediacapture-main/issues/640 so its in-content selector would be inferior by default:
* Camera 1
* Logitech BRIO
* Camera 3
This is where a spec-mandated picker would be valuable, giving sites A) a choice about whether they want to handle all this complexity or not, and B) a more compatible way to ask users the same thing that works with stricter-permission browsers (like Firefox). A win for privacy.
I'm happy to have in-chrome compete with in-content. I think we can make it superior.
> Headset detection
@juberti How is that done? By the browser or the app? By browser is not web compatible. By app we still have `groupId`.
> and auto-selection?
Not sure what that is, but sites could still select the system default by specifying the first deviceId from `enumerateDevices()` like today if not having a selector up front is truly important to them:
```js
getUserMedia({video: {deviceId: {exact: deviceInfo.deviceId}}}); // Selector-free
```
See https://github.com/w3c/mediacapture-main/pull/644#issuecomment-566248295 for full table.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/652#issuecomment-567302999 using your GitHub account
Received on Thursday, 19 December 2019 02:30:16 UTC