Sounds reasonable.  Presumably, this would not be a useful input to gUM as a constraint.  Do you believe that this needs to be addressed somehow?  Could we reasonably forbid its use as a constraint?

Agree, but perhaps rather than "unknown" this case should simply be JS's undefined property?

I suggested this by considering the following scenario.

If MediaStreamTrack.states() is invoked from the JS, it will return "MediaSourceStates", which internally contains "VideoFacingMode".
This attribute should be filled inside the browser. 

If browser don't know the exact direction facing of the camera, then spec is not providing any option to fill in. Then browser has to fill in either assumed or wrong default value or fill it with a NULL-String ("").

AFAIK Instead of returning NULL-String to JS, it is good to fill some predefined value like "unknown".

I actually like Paul's suggestion.  If you don't know the value, don't provide one.

I feel, if the value is not known, then browser should convey the same to JS. Other wise spec should explicitly specify that browser should return a NULL string in case of unknown facing mode.

(In reply to Kiran from comment #5)
> I feel, if the value is not known, then browser should convey the same to
> JS. Other wise spec should explicitly specify that browser should return a
> NULL string in case of unknown facing mode.

All members in dictionaries are optional - and constraints/settings/capabilities work like dictionaries in most respects - so I believe the browser can omit the facingMode member entirely rather than fill it with an empty string (which would be an illegal enum member currently).

Similarly, I would expect getCapabilities() to only contain facingMode when it is known.

However we achieve it, I agree this needs clarification.

I would also like clarification on whether the following excludes a "camera of unknown direction":

{video:{mandatory:{facingMode:['user','environment','left','right']}}}

I assume yes.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #6)
> However we achieve it, I agree this needs clarification.

Sure.
 
> I would also like clarification on whether the following excludes a "camera
> of unknown direction":
> 
> {video:{mandatory:{facingMode:['user','environment','left','right']}}}
> 
> I assume yes.

Likewise.  Perhaps the reason that the camera is not given a facing mode from the selected set is that it *is* known, but not one of the four provided options.  Unset wouldn't be strictly "I don't know" it would also encompass "none of the above".

+1 for omitting unknown properties because there is no way to guarantee that the browser can even see all properties to begin with. Meaning, some properties are unknown because we can see them but don't understand their meaning. Other properties are not visible because a browser may query "basic" properties but omit querying for more "advanced" properties. Under OSX, for example, the functionalities exposed by QtKit and AVFoundation driver APIs are not identical so depending on which interface you use to query a device you will see different capabilities.

Just to take both positions here, one argument FOR "unknown" would be to future-proof so we can add new enum values in the future. This would rely on Bug 19936 being addressed, which would let us write:

enum VideoFacingModeEnum {
    "user",
    "environment",
    "left",
    "right",
    "unknown" = default
};

(In reply to Jan-Ivar Bruaroey [:jib] from comment #9)
> Just to take both positions here, one argument FOR "unknown" would be to
> future-proof so we can add new enum values in the future. This would rely on
> Bug 19936 being addressed, which would let us write:
> 
> enum VideoFacingModeEnum {
>     "user",
>     "environment",
>     "left",
>     "right",
>     "unknown" = default
> };

This is what I expected it to be.

R

(Above: New personal record for shortest message before accidentally hitting the submit button :) )

Do we have to rely on the resolution of bug Bug 19936 to future-proof the enum? I noted that, for ECMAScript, assignments to enum attributes are ignored if the new value isn't a valid enum value, but an invalid enum value as a function argument generates an error. I would expect an assignment to a dictionary member to be similar to the attribute assignment case. Not sure though.

(In reply to Adam Bergkvist from comment #12)
> Do we have to rely on the resolution of bug Bug 19936 to future-proof the
> enum?

I don't think so, I marked it as a dependency more to revive the other bug.

> I noted that, for ECMAScript, assignments to enum attributes are
> ignored if the new value isn't a valid enum value, but an invalid enum value
> as a function argument generates an error.

Yes, from http://www.w3.org/TR/WebIDL/#idl-enums

> I would expect an assignment to a dictionary member to be similar to the
> attribute assignment case. Not sure though.

Unfortunately, dictionaries are always function arguments (they can't be attributes), so invalid facingModes throw, hence Bug 19936.

I suggest two actions here:

1. Add "unknown" as Kiran suggests in comment 0.

2. Use DOMString for facingMode and refer to VideoFacingModeEnum in a
   comment as a workaround for now, as I suggest in Bug 19936 comment 5.

(In reply to Paul Neave from comment #2)
> Agree, but perhaps rather than "unknown" this case should simply be JS's
> undefined property?

"unknown" = not left, right, user or environment, but something else.
"undefined" = unconstrained.

These are different. I think it would be quite fun actually to constrain on "unknown". Give me all your new and wonderfully odd cameras!

Also, since we don't have negative constraints, this lets us express things like "not environment" using exclusion ['user', 'left', 'right', 'unknown'].

Perhaps a better name would be "other"?

(In reply to Jan-Ivar Bruaroey [:jib] from comment #13)
> (In reply to Adam Bergkvist from comment #12)
> Unfortunately, dictionaries are always function arguments (they can't be
> attributes), so invalid facingModes throw, hence Bug 19936.

I was referring to the value assignment of a dictionary member (not the entire dictionary).

foo.attr = "not-in-the-enum"; // ignored (from WebIDL spec example)

enumArgFunc("not-in-the-enum"); // error  (from WebIDL spec example)

var dict = {
  member = "not-in-the-enum" // this is the case: ignored or error?
};

(In reply to Adam Bergkvist from comment #15)
> I was referring to the value assignment of a dictionary member (not the
> entire dictionary).
> 
> foo.attr = "not-in-the-enum"; // ignored (from WebIDL spec example)

As I understand it, WebIDL dictionaries returned to JS are not browser objects but POS (plain old JavaScript objects), so foo here is a POS and I wouldn't derive much from that.

> var dict = {
>   member = "not-in-the-enum" // this is the case: ignored or error?
> };

I think you mean: var dict = { member: "not-in-the-enum" ); and dict is also a POS.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #16)
> (In reply to Adam Bergkvist from comment #15)
> > var dict = {
> >   member = "not-in-the-enum" // this is the case: ignored or error?
> > };
> 
> I think you mean: var dict = { member: "not-in-the-enum" ); and dict is also
> a POS.

You're right (about the syntax too)

(In reply to Jan-Ivar Bruaroey [:jib] from comment #14)
> (In reply to Paul Neave from comment #2)
> > Agree, but perhaps rather than "unknown" this case should simply be JS's
> > undefined property?
> 
> "unknown" = not left, right, user or environment, but something else.
> "undefined" = unconstrained.
> 
> These are different. I think it would be quite fun actually to constrain on
> "unknown". Give me all your new and wonderfully odd cameras!
> 
> Also, since we don't have negative constraints, this lets us express things
> like "not environment" using exclusion ['user', 'left', 'right', 'unknown'].
> 
> Perhaps a better name would be "other"?

I don't have any problem with name, whether it is "unknown" or "other". I concentrated much on the feature.

The intention of proposing "unknown" is to cover the case where

1. Direction of facing is UNKNOWN in cases where we connect an external camera using USB / bluetooth (ofcourse user can change the direction in the middle of the session).
2. Rotating cameras apart from fixed top, down cameras.

Discussed at the May 19 Media Capture TF meeting.

Conclusions:
- "Other/Unknown" will be represented as a missing value - that is, JS "undefined"
- Due to the issues with Enum in a dictionary, DOMString will be used
- Jan-Ivar took on the task of creating a text proposal

Pull request: https://github.com/fluffy/webrtc-w3c/pull/34

Note that pull request in comment 20 adds an "other" enum entry for UAs to coerce unknown strings into. This is useful for implementations, as it lets them translate incoming strings into an enum internally, as a point of parsing. As a consequence, JS users may see this value in constraints returned to them from APIs that return constraints, in place of the original string, which is not kept.

*** Bug 25793 has been marked as a duplicate of this bug. ***

Re-assigned. To be reviewed now that PRs #14 and #16 have been merged.

I think this was resolved with using JS undefined