Re: How Firefox implements optional constraints

On 11/14/13 8:23 PM, Silvia Pfeiffer wrote:
> On Fri, Nov 15, 2013 at 5:31 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#750
>>
>>    // Then apply optional constraints.
>>    //
>>    // These are only effective when there are multiple sources to pick from.
>>    // Spec as-of-this-writing says to run algorithm on "all possible tracks
>>    // of media type T that the browser COULD RETURN" (emphasis added).
>>    //
>>    // We think users ultimately control which devices we could return, so
>> after
>>    // determining the webpage's preferred list, we add the remaining choices
>>    // to the tail, reasoning that they would all have passed individually,
>>    // i.e. if the user had any one of them as their sole device (enabled).
>>    //
>>    // This avoids users having to unplug/disable devices should a webpage
>> pick
>>    // the wrong one (UX-fail). Webpage-preferred devices will be listed
>> first.
>>
>>
>> Clarification: The first device in the returned list becomes the default
>> choice, so the webapp gets what it wants, as before, unless the user
>> *explicitly* overrides the default with another device that the app has
>> disclosed it also works with (a want not a need).
>>
>> Another way to express this is as a fairness problem in the reductive
>> optional algorithm: the fewer devices users disclose, the more choices they
>> get. We should remove impediments to users disclosing all their devices to
>> the browser.
> You seem to be repeating this ability of the user to hide devices from
> the browser.
> I have not seen that possible in reality, other than doing it on the OS level.
>
> Rather: I have seen devices (including stereo cameras) exposed to the
> browser (and accessible to the JS dev via getSources()).
> The browser will just expose what it is able to see from the OS -
> which in the case of a stereo camera is that it simply is exposed as a
> normal camera.

The user can unplug the camera or disable it in Device Manager. OS affects browser, that's not the relevant part. I'm not saying it is convenient for users to do this, quite the opposite, I'm saying it is hugely inconvenient (and often impossible on phones). I see that as a usability disadvantage. Do you see it as an opportunity?

> I also disagree with the comment in the Firefox source code from my
> experience with Chrome.
> The way constraints work there is that you ask for a constraint which
> can also refer to just a single camera.
> For example, I have a webcam attached and I request a HD stream from
> that camera.
> That comment tells me that Firefox is going to ignore that request by
> me, which is unfortunate.

No, Firefox will not ignore your optional request. At the risk of repeating myself: your preferred camera is chosen by default.  The user has to explicitly intervene and say that the camera that you chose, on their system, doesn't work for them.

The camera may look perfect to you, but if it is fix-mounted at the cat litter-box, then it is probably the wrong one. The user knows this, you don't. Users probably wont blame you for initially picking it, but might be irritated if they are unable to correct it.

Firefox looks at:
  1. What does the app prefer
  2. What can the app support
  3. What does the user know

Example (and to be clear, we're talking about optional constraints only here):

Using any webrtc-enabled browser, take 100 users, half of them have the property you want (not need) and half don't. Your app will work for all of them. Half of them get a superior experience, and the other half get an inferior one, but they all get one. This is undisputed.

We're arguing over whether users themselves should have to unplug their camera if they have reasons to want to move from the first group to the second (from a superior camera to an inferior one). In some situations, like on a phone, unplugging is not even an option. The back camera may always have higher resolution, but that doesn't mean users don't want to switch to the front sometimes.

You, the webdev, is just looking at the specs of the camera, you don't know much about it's physical situation or what it is pointing at in the user's space. Consider why a user may have multiple cameras in the first place. Is it solely to possess multiple camera properties?

And facingMode is not a panacea. Hopefully no-one thinks a 'litterbox' facingMode will cure this (not that we support negative constraints anyways, something we can fix, and something I hope isn't the lone obstacle to this constraint's existence).

> I think there seems to be a misunderstanding between Firefox devs and
> the spec devs/Chrome devs. This needs to be sorted out.

The spec is vague about the devices "that the browser could return", and does not preclude this interpretation IMHO. - FWIW Firefox and Chrome differ in other respects as well when it comes to camera selection and permissions. The spec is free to leave some things to implementations.

.: Jan-Ivar :.

> Regards,
> Silvia.
>
>> I'd like to propose that this behavior be made explicit in the spec, rather
>> than left to be inferred by implementations.
>>
>> .: Jan-Ivar :.

Received on Friday, 15 November 2013 16:01:01 UTC