UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

Steps to reproduce the problem:
Call getUserMedia with a bunch of advanced constraints, first some to choose minimal widths and then some to choose maximal aspect ratio. The goal is to maximize width, and from all with maximal width then pick one which maximizes height as well.

What is the expected behavior?
Since the camera supports 1280×720, the requirement for a minimal width of 1280 should be satisfiable, so at that point of the applyConstraints algorithm all candidates with lower width should be discarded. We should get something with 1280 width or more, definitely not less.

What went wrong?
Chrome chooses 964×720 instead, thus apparently giving the aspect ratio selection priority over the width selection without regard to the order of constraint sets. Commenting out the aspect ratio constraints makes Chrome choose 1280×720 instead.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 54.0.2840.59  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0

See https://w3c.github.io/mediacapture-main/#dfn-applyconstraints for details on the selection algorithm. In particular “If the fitness distance is finite for one or more settings dictionaries in candidates, keep those settings dictionaries in candidates, discarding others.”

See  bug 543997  for the implementation of the new constraints API as a whole. See in particular https://bugs.chromium.org/p/chromium/issues/detail?id=543997#c49 indicating that the ideal dimension constraints are without effect so that part of my test case is a known problem but not the issue I'm reporting here.
 

Deleted: rtc.html 895 bytes

rtc.html 895 bytes View Download