Should getCapabilities() return an empty array or undefined for facingMode?

[youennf]

As pointed by Eric, on macOS, Chrome and Safari capabilities for a camera track differ for facingMode.
Safari does not include facingMode, Chrome sets it to [].
The spec does not seem to provide guidance for facingMode.
It would be good to be consistent and either use undefined or [].

[jan-ivar]

I think the spec guidance is there: "For each constrainable property, there is a capability that describes whether it is supported by the source and if so, the range of supported values".

Chrome sets it to [].

I can repro with https://jsfiddle.net/jib1/3gpy9ndz/ — The constraints concept being a triad, my takeaway is one of the intended invariants is that any value exposed in either getSettings or getCapabilities also appears in the other.

It seems a bug to surface a value in only one of getSettings and getCapabilities.

[guidou]

It seems a bug to surface a value in only one of getSettings and getCapabilities.

I agree with this. I filed a bug to track a fix so that the capability is not exposed as an empty array if the setting is not exposed.

Not sure if we need to amend the spec in any way.

[jan-ivar]

A note would probably be nice.

[alvestrand]

The likely reason for the empty array is platform dependence - I think we support "user" and "environment" on Android, but in general on the PC platforms, we have no way of knowing which way the camera is facing. So we support the constraint in code (and thus generate an element for it in capabilities), but on the platform the test runs on, there are no applicable values.

Seems a bit weird. But if we drop empty arrays for this case, we should drop it for all cases.

[alvestrand]

Note that there's a behavioral difference: if we make a mandatory (exact/min/max) on a constraint that is supported but has no applicable value, the request will be rejected as overconstrained. If we make a mandatory on a constraint that is not supported, the constraint is ignored.

So this may warrant a spec change for clarification.

[guidou]

The likely reason for the empty array is platform dependence - I think we support "user" and "environment" on Android, but in general on the PC platforms, we have no way of knowing which way the camera is facing. So we support the constraint in code (and thus generate an element for it in capabilities), but on the platform the test runs on, there are no applicable values.

This is correct, and I don't think there is anything in the spec that explicitly prohibits this behavior.
Also note that Chromium also supports facingMode values on Windows and ChromeOS, which have APIs to get this information.