Open Bug 1695394 Opened 4 years ago Updated 1 year ago

Advanced constraints should not eliminate devices in getUserMedia

Categories

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

defect

Tracking

()

People

(Reporter: jib, Assigned: jib)

References

Details

We've recently seen sites like Whereby use advanced constraints in a way that causes Firefox's permission prompt to only offer one camera, even though they don't require any constraints.

This overconstraining seems undesirable and doesn't map to site expectations. This problem has always existed, but new site practices and Proton improvements with bug 1693644 will make the problem more visible now.

STRs:

  1. Attach a Logitech BRIO to a Macbook pro
  2. Open https://jsfiddle.net/jib1/dzpqobr7/
    video.srcObject = await navigator.mediaDevices.getUserMedia({
      video: {
        advanced: [
          {width: 1280},
          {height: 720},
          {width: 1024},
          {height: 576},
          {width: 640},
          {height: 360}
        ]
      }
    });
  1. If you're not prompted for permission, clear permission and go to 2.

Expected results:

  • Firefox's camera permission prompt lets you choose between "Logitech BRIO" and "FaceTime HD Camera (Built-in)"

Actual results:

  • "Logitech BRIO" is the only option.

The relevant spec suggests the expected results: "Run the SelectSettings algorithm on each track in candidateSet with CS as the constraint set. If the algorithm returns undefined, remove the track from candidateSet." — But SelectSettings can only return undefined as a result of infinite fitness distances in step 4, which is before advanced constraints are considered in step 5.

But it also says do whatever we want: "The decision of which track to choose from the finalSet is completely up to the User Agent and may be determined by asking the user. ... The User Agent SHOULD use the value of the computed fitness distance from the SelectSettings algorithm as an input to the selection algorithm. However, it MAY also use other internally-available information about the devices, such as user preference."

We're the only browser to implement "asking the user", and there's no spec requirement here that we need to limit the pool of choices based on advanced constraints, so we shouldn't.

The offending code is here and is outdated.

There may be some merit in keeping the logic when persistent permission is used, in order to ensure the user agent picks the most suitable device. OTOH, relying solely on fitness distance may prove more web compatible.

Assignee: nobody → jib
Severity: -- → S3
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.