Re: CHANGE: Use a JS Object as an argument to getUserMedia

On Thu, Oct 6, 2011 at 3:10 PM, Anant Narayanan <anant@mozilla.com> wrote:

I agree that the question is tricky, but it is something that we no doubt
> have to handle. I think that we absolutely should let the user deny either
> video or audio even if the application requested both (what are the
> arguments for not allowing this?). The real question is of how this
> information is relayed back to the application.


I have a few of arguments against this:

1) It allows the user to accidentally make contradictory/invalid selections.
For example, a user may indicate to the app that they want to start a
voice+video call, then when prompted by the browser mistakenly select the
"just video" option. What should the app do at this point? Display an error
message and force the user to start over again? Start a call with just the
video track and leave the user to wonder why the other party can't hear
them?

2) It requires the user to understand the difference between granting
permissions and enabling tracks. Let's say that a user wants to start a
voice call with the option of enabling video after the call starts. As I
understand it, the app should request audio+video access and then disable
the video track, re-enabling it when the user elects to start video. But the
user, upon seeing a request for audio+video permissions despite the fact
that they hit the "start voice" button in the app, may choose "just audio",
unwittingly denying themselves the ability to enable video later.

3) The dialog presented to the user when an app requests audio+video will
most likely have two checkboxes (audio and video) and two buttons (allow and
cancel). If the app can specify that both tracks are required, the dialog
can get away with just the buttons, which makes for a much more pleasant
user experience.

As an app developer, I'd like to be able to specify one of three options for
each media kind: REQUIRED, REQUIRED_IF_CAPABILITY_EXISTS, and OPTIONAL. When
implementing a voice+video calling app, I'd pass REQUIRED for audio and
REQUIRED_IF_CAPABILITY_EXISTS for video, which would make video required iff
the device has a camera available. That way, if the call to getUserMedia()
succeeds, I know that I have the "right" tracks given the user's intent and
device capabilities (as an aside, detecting failure would be a lot easier
with the callback api).

I'm actually having a hard time thinking of a use-case for OPTIONAL, since
apps will generally ask the user to select media types before calling
getUserMedia(). For example, a recording app will almost certainly have
separate "record audio" and "record audio+video" buttons rather than a
generic "record" button which relies on the permissions dialog to determine
the user's intent.

Ben