Prompt user to choose unless constraints reduce to 1.

[jan-ivar]

Fixes https://github.com/w3c/mediacapture-main/issues/652 #640.

[alvestrand]

If this does what the title says, I'm against it.

Prompting the user to choose when the user has a stored permission to access all the devices in the list will lead to completely pointless prompting - more user annoyance, and no added security benefit. The platform should pick the best device in this case.

If there is a single device with permission and 1 or more devices with no permission, I could see an argument for prompting the user to choose.

Chrome currently uses the model of "either you have permission to all cameras or none". I don't want to make the spec attempt to outlaw that model.

[alvestrand]

The removing of the "open track" provision seems like a drive-by edit in this context.
The reason we added the "open track" provision was that:

stream = getUserMedia({video: {device-id: device-id-of-old-track}})

seemed silly to disallow (no added security benefit) when the page could already do

stream = old-stream.clone()

and in some cases the gUM flow was more natural.

[jan-ivar]

If this does what the title says, I'm against it.

Please see this slide which I unfortunately ran out of time to present properly last week.

Prompting the user to choose when the user has a stored permission to access all the devices in the list will lead to completely pointless prompting

Not so, unless you assume sites don't use constraints? The whole premise of in-content device selection rests on sites responsibly using constraints to remember choices for their users.

Multi-device users of sites that abdicate this responsibility would likely welcome a selector.

But most users would not see a prompt with this change, I claim:

1. Users with just one camera + mic
2. Users with front/back cams: no prompt on sites using facingMode: {exact}
3. Users with multiple cams+mics: no prompt on sites using deviceId: {exact}

The only people who would see a selector are those with an actual choice, and where a site abdicates its responsibility to pick responsibly for their users.

Yes, this small sub-population would see a selector initially for a while. This seems like a safe transition given that most browsers today lie about how many devices users are sharing. #648

Sites can avoid an initial selector by guessing the user prefers their default device like this:

const devices = await navigator.mediaDevices.enumerateDevices();
const exact = devices.find(({kind}) => kind == "videoinput").deviceId; // use 1st cam
await navigator.mediaDevices.getUserMedia({video: {deviceId: {exact}}});

From my testing (and it's now in the spec even), all browsers list the default device first.

pointless prompting

I'd argue the spec is broken today except for browsers that grant all cams/mics upfront.

There's pointless prompting in all other models: First from in-content picker + again from browser.

[youennf]

I like the intent to allow authorising a single capture device.
The spec should allow this model and hopefully experiments can be done in that area to help clarifying the transition path. This is not a trivial task though and will probably require some time to complete.

I don't understand why the PR is in one case, requesting permission to use and in the other case prompting the user to choose. It seems to me we should always prompt the user to choose, even if there is only one choice. For instance, Safari implements getDisplayMedia and only supports capturing of the current screen. I do not see Safari as being not compliant there.

[jan-ivar]

We want to support persistent permissions. getDisplayMedia does not.

[youennf]

We want to support persistent permissions.

I quite like the idea of showing the camera feed and clicking on it as a selection even if there is only one camera. This in particular makes sense when diving in a vc room. Makes less sense for microphone.

Per-device persistent permissions is an interesting topic.
I am not sure how easy it will be to show these settings to the user (per origin/per device).
Safari is currently using per device type which is easy to understand to the user.

[jan-ivar]

To be clear, I wasn't specifically talking about per-device persistent permission. Even Firefox persists by type if asked to persist. But the PR is this way to enable existing permission models too.

[jan-ivar]

@alvestrand I've put back the "open track" provision. Thanks for pointing that out. I realized I didn't need it.

[jan-ivar]

To clarify this PR: I believe these changes to getUserMedia are the best path toward to it becoming useful as an in-chrome picker.

It should be highly web compatible since most users won't see a change. #644 (comment)

From slide:

User with previously persisted permission for camera:	Single camera	Front/back camera	Multiple cameras
getUserMedia({video: true}) getUserMedia({video: {facingMode: "user"}}) getUserMedia({video: {deviceId: cameraId}})	Granted!	Selector!	Selector!
gUM({video: {facingMode: {exact: "user"}}})	Granted!	Granted!	Selector!
gUM({video: {deviceId: {exact: cameraId}}})	Granted!	Granted!	Granted!

User without persisted permission: replace “Granted!” with “Selector!” or “Prompt!”

[youennf]

I am fine with a PR allowing a browser to implement a device picker only in the case where there is more than one device to choose from.
I am not sure that "request permission to use" is not allowing this already.

I think it is good to be vague in that area to allow browsers to investigate various strategies.

As a user, I am not sure I would like an experience where sometimes a website can start capturing after I select explicitly a device and sometimes the same website can start capturing without that step.

[jan-ivar]

I am fine with a PR allowing a browser to implement a device picker only in the case where there is more than one device to choose from.

@youennf Great! That's what this PR aims to do.

I am not sure that "request permission to use" is not allowing this already.

It does, but merely allowing it doesn't make getUserMedia a reliable selector. When I click here:

...I want to write:

button.onclick = async () => {
  if (numberOfVideoInputDevices > 1) {
    const c = {video: {deviceId: cameraTrack.getSettings().deviceId}};
    cameraTrack = (await navigator.mediaDevices.getUserMedia(c)).getVideoTracks()[0];
  }
}

...and have that bring up a browser picker in all browsers (with "Logitech BRIO" as current choice).

This needs to be guaranteed, to replace in-content selection, which won't happen from vague prose.

[alvestrand]

I think consensus at the VI was that a new API to require a picker was a Good Thing (either new argument or new function), but that changing the semantics of the existing call was not.
Should we close this PR and start a new one?

[alvestrand]

Basic algorithm will be the same, but closing this PR - @jan-ivar to make a new PR with a new title.