Closed Bug 1561319 Opened 1 year ago Closed 1 year ago

WPT mediacapture-streams/GUM-invalid-facing-mode.https.html fails

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

67 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: pehrsons, Assigned: pehrsons)

References

()

Details

Attachments

(1 file)

This is because the fake video device ignores all constraints except deviceId.

It seems ok to ignore the range ones, like width, height and frameRate, but right now for facingMode this accepts all sorts of values.

This does two things:
It makes MediaEngineDefaultVideo::GetBestFitnessDistance include a facingMode
check.
It also makes FitnessDistance() for StringRanges take a Maybe<nsString>, since
the device might not have a value for all StringRange constraints, as is the
case for facingMode. This fixes this issue for a MediaEngineRemoteVideoSource
with no facingMode, since such a device would match a facingMode of the empty
string prior to this patch.

To be fully spec compliant, the Maybe should be a set instead, since a device
may support multiple values for the facingMode capability. We don't support
more than one value however, so this change can be made later as needed.

Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/324c7b90a7cc
Check facingMode constraint in MediaEngineDefaultVideo and don't match empty string by default. r=jib
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.