Closed Bug 905696 Opened 11 years ago Closed 3 years ago

Support application preferences for cameras and mics in getUserMedia() prompts (Desktop)

Categories

(Firefox :: Site Permissions, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1693644

People

(Reporter: jesup, Unassigned)

References

Details

(Whiteboard: [getUserMedia])

When implementing constraints for bug 882145, we'll need the UI to support being told that a specific device should be the default one shown to the user.  No string or other changes should occur; it's solely changing the default from the first device to a specified one. API TBD in bug 882145.

This bug is for the desktop platforms; separate bugs will be cloned off it for Android and B2G.
Whiteboard: [getUserMedia]
Do we really even need to implement this UI for desktop? It would seem quite rare for a desktop to have multiple camera options, so I'd put this at a pretty low priority at most.
Summary: Support application preferences for cameras and mics in getUserMedia() prompts → Support application preferences for cameras and mics in getUserMedia() prompts (Desktop)
Component: General → Device Permissions
Users of the OpenTok platform (www.tokbox.com) have been requesting this functionality for awhile. One of the main use cases is to use the enumerateDevices API and pass a specific camera (or microphone) as a constraint for getUserMedia(). We have enough demand for device selection that we have created a hardware set-up component (https://github.com/opentok/opentok-hardware-setup.js) to assist the user in selecting a camera and microphone. This works perfectly in Chrome. But in Firefox, when the user selects a device, the browser prompts them to select it a second time (due to this bug).

This has been overtaken by events.

Applications have years now been able to use required constraints (exact, min & max) to filter the list shown down to a single device if necessary (e.g. {deviceId: {exact: id}}),

OR use optional constraints (idealor plain values) to affect the order (ordered by best-fit) and default shown (e.g.{deviceId: id})

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

This works perfectly in Chrome. But in Firefox, when the user selects a device, the browser prompts them to select it a second time (due to this bug).

This is rooted in a permission model difference with Chrome. Chrome always grants permission to ALL cameras, whereas Firefox only grants the camera (the application or) the user chooses. Ditto mic. But this is a prompt for permission first, not primarily a picker.

It is also rooted in a misunderstanding of the Firefox permission prompt's picker feature. This is a supplementary feature without any memory or intention of managing devices for the user. This remains the responsibility of sites in the web-model. The (optional) picker has no memory of its own, and is merely meant as a web-compatible way to let users get their choice in early for this site (it relies on the site storing deviceIds they get back from getUserMedia as they would from their own ⚙️ settings page).

We've made some improvements in this area recently:

  • Bug 1693677 adds a permission grace period, which should reduce the number of prompts while a user is flipping between cameras/microphones, to only appear the first time a new device is chosen.
  • Bug 1693644 shows a label instead of a picker-of-one device when a single device is requested.

Even though the latter is largely cosmetic, it fixes a problem that reenforced a misunderstanding (among users and web developers) that the Firefox picker was somehow competing with the site's picker, when it truly wasn't. With this change, it should be clearer that when a site is doing the picking from its ⚙️ settings page, the Firefox prompt that may appear is merely a permission confirmation of the choice already made (and should appear less often due to the grace period).

See Also: → 1693677, 1693644
Resolution: WORKSFORME → DUPLICATE

We're also considering extending the grace period significantly in bug 1697284.

See Also: → 1697284
You need to log in before you can comment on or make changes to this bug.