Re: [mediacapture-main] "user-chooses": Does required constraints make any sense now? (#669)

So we have some experience with in-browser camera & mic pickers in Firefox to draw on.

> The problem we want to solve here is removing label info either entirely or for devices not used by the given web page.

I agree on the problem statement, but I see no reason to change our whole model over it. Conservatively if we look at how labels are used today, sites build rudimentary pickers. All they need to replace that effort is a tool to provoke an in-browser picker. This already almost works in Firefox by default, which is why I find it hard to comprehend what a leap this is for some:
```js
await getUserMedia({video: {deviceId: {exact: [...allOtherDeviceIds]}});
```
Admittedly, the above has API problems and UX problems, but we need to separate them:

**The API problems:**
1. Won't prompt once you check `☑ Remember this decision`. It's still a _permission_ prompt.
1. For web compat, we [can't](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-same-permission) prompt if site already has permission to one of the choices.

**The UX problems** (which are _orthogonal_ i.e. _**already exist today on second-device requests!**_):
1. Canceling a second-device request is overly harsh on the site. [Bug 1609578](https://bugzil.la/1609578)
2. Our UX heavily biases toward a default choice, too many clicks to change device.
3. Our (lack of) preview is biased toward initial prompt (where it might freak people out)
4. We don't do a good job of simplifying our UX when there's just one choice.

If you work on (or predominantly use) a browser without per-device permission (that doesn't tell you which device you're sharing), you'll be forgiven for thinking these problems as intrinsically linked. They are not.

We solve the API problems with:
```js
await navigator.mediaDevices.getUserMedia({video: true, semantics: "user-chooses"});
```
This would be enough to force all user agents to show a picker of all devices.

This seems to solve the API problem with no change to the model, with near-parity with all existing in-content device selection I've seen.

That wins in my book. Leave UX to user agents.

Now there are interesting UX-related corner cases here we can discuss in the interest of sharing, but I want to leave the pie in the sky first.

> allow a user agent to only expose granted devices as part of enumerateDevices.

We have a basket for that. Just like https://github.com/w3c/mediacapture-main/issues/646 would prevent sites from optimizing out camera- and mic-launching buttons, removing info of other devices would prevent sites from optimizing out camera- and mic-changing buttons in their config panel(s).

The "interesting" UX-related corner cases I alluded to, include what to do e.g. when there are no good choices.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/669#issuecomment-605079756 using your GitHub account

Received on Friday, 27 March 2020 15:59:50 UTC