-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enumerateDevices() should request permission #874
Comments
I do not think we can make enumerateDevices trigger a prompt as is:
Last issue is solvable, we should probably move this issue to mediacapture-extensions in any case.
I don't see why user would be confused. |
The user gets confused because we have to request a camera/microphone stream before we can even prompt them for which camera/microphone they want to use. This isn't a hypothetical... it's a common source of confusion for our users. And, having to turn around and stop the stream we just opened is a source of further problems. Webcam light may turn on briefly, then off. System may run slower for a few seconds. Sometimes closing and re-opening cameras repeatedly can be problematic. Having to open a camera before getting a camera list is a hack. We're forced to use it because of this standard.
Calls to Regardless, an alternative is to add some other way to request permission as an independent step to capturing or enumerating. Then, this is solved by something like this:
|
enumerateDevices() without permission is allowing to know whether there are camera or microphones. |
Note enumerateDevices is called by trackers in 8% of pages, dwarfing
Why should users have to grant permission to all cameras to use one? That's an undesirable permission escalation from Mozilla's perspective, and the TAG agrees: "This specification exposes device information of devices other than those in use. This is for backwards compatibility and legacy reasons. Future specifications are advised to not use this model and instead follow best practices as described in the device enumeration design principles."
This has the same permission escalation problem. Another alternative is to look at what Firefox implements:
This seems to solve your problem without violating W3C design principles, so this doesn't seem to be a spec problem. |
Currently, to get a media device list we must first make a call to
getUserMedia()
. This creates UX headaches for use cases where the user needs to pick a device first, and capture from it second. The current flow looks like this:getUserMedia()
before callingenumerateDevices()
.getUserMedia()
.enumerateDevices()
, and shows the user a selection of devices to choose from.getUserMedia()
to get the stream.What would be more desirable:
enumerateDevices()
.getUserMedia()
and gets a stream, without requiring additional approval from the user.In other words, if the browsing context doesn't yet have audio/video capture permission before calling
enumerateDevices()
, that permission should be requested beforeenumerateDevices()
resolves. And, the same permission gate forgetUserMedia()
should be used, so that if/when we eventually do callgetUserMedia()
, it's already been approved.enumerateDevices()
is already promise-based, so this seems mostly compatible with existing APIs.Ideally,
enumerateDevices()
would also contain a filter option (#522) so that if an application only needed audio or video permission, they could request just what is needed.This type of flow is important, particularly for applications where several tracks are used simultaneously. I understand in the past that there was a desire to have the user agent control device selection, but this is not a good user experience for anything outside of the a basic single-stream video conferencing application.
The text was updated successfully, but these errors were encountered: