Marking the above issue as Untriaged as this is a new feature request.

Dev team will take a call on the above request.

Thank you!

jsfiddle reproducing the current appear.in behaviour (which is going to change soon): https://jsfiddle.net/yn5dph2u/1/

I can't reproduce the meet.jit.si behaviour but https://jsfiddle.net/h5tfakr4/1/
is odd. An error indicator is shown even though audio access works.

This is an old and known issue which happens due to the current UI does not handle separate device permissions if they are different from one another. We have an old internal bug 347157 where this has been discussed since M33 (and even earlier but the bug was filed then).

Also, the UI is only for permissions rather than a control knob for the device like on Firofox i.e. it checks the permission when the gUM request is made but after the request has been made, the permissions no longer matter for the existing streams.

AFAIK the conclusion was to wait and see how the getSources/mediaDevices/enumerateDevices would pan out as well as landing the output device enumeration and selection since those would affect the permission UI.

Now that all that has landed I do not know what the current status. tommi@ might know more?

this is inconsistent even with the UX in the success case.
Calling this in succession
  navigator.mediaDevices.getUserMedia({audio: true})
  navigator.mediaDevices.getUserMedia({video: true})
leaves me with a dialog that lets me make decisions about both audio and video.

further: I have blocked camera access for https://jsfiddle.net/yn5dph2u/1/ but am allowing microphone. Audio access works, stream.getTracks() returns an audio track (which is not compliant with the spec but...)
Hovering over the camera icon in the address says (german, h/t blum@):
  diese seite darf nicht auf die Kamera und das Mikrofon zugreifen
(roughly: not allowed to acccess camera and microphone)
At best, that is an incorrect translation, the site is accessing the microphone (and the red dot is shown).  

and another one: suppose the user has blocked permission to one of the devices, e.g. video.
This means that calling GUM with {audio: true, video: true} will fail with NotAllowedError (?)
How can the application figure out that there is a chance that falling back to audio works? I'd prefer not to have a fallback mechanism that needs to guess even though I suspect that I might use enumerateDevices' .label to make smart decisions here in some cases.

Did I mention that I find this confusing? ;-)

enumerateDevices helps detect users without a camera or mic [1], but not blocked permissions.

As to Comment 6, FWIW using a fallback should always be safe I believe, e.g. [2]:

    gUM({video: true, audio: true})
    .catch(e => (e.name == NotAllowedError) ? gUM({video: true}) : Promise.reject(e))
    .catch(e => (e.name == NotAllowedError) ? gUM({audio: true)) : Promise.reject(e));

should never double-prompt (If the user had previously blocked camera only then they only get a prompt on the third call. OTOH if the user had not blocked anything, then they get a prompt on the first gUM call, and if they choose to block (both) at that point, they'll not see a prompt on the second and third call).

[1] http://stackoverflow.com/questions/25308486/make-video-stream-optional-in-getusermedia/33770858#33770858

[2] s/NotAllowedError/PermissionDeniedError/

Comment on #4:

"Calling this in succession
  navigator.mediaDevices.getUserMedia({audio: true})
  navigator.mediaDevices.getUserMedia({video: true})
leaves me with a dialog that lets me make decisions about both audio and video."

This is per spec's implementation advice, 10.6 best practice 3:

"A single call to getUserMedia() will always return a stream with either zero or one audio tracks, and either zero or one video tracks. If a script calls getUserMedia() multiple times before reaching a stable state, this document advises the UI designer that the permission dialogs should be merged, so that the user can give permission for the use of multiple cameras and/or media sources in one dialog interaction. The constraints on each getUserMedia call can be used to decide which stream gets which media sources."


If the advice is followed, getUserMedia({audio: true}).then(s => getUserMedia({video: true}) should give two prompts, if there's a desire to demonstrate that.

#8: yes, this is good behaviour for the success case. The permission dialogs are not merged for errors or revoking permissions which is not consistent with that.

Is that spec still tweakable such  that it says '...can give or revoke permission for...'?

File a bug in github and make a PR for the spec, and we'll consider it.
yes, the spec is still open for bug-fixing.

(Even better - make w3c tests that expect the Right Thing to happen, and submit them to the w3c test repo. We'll get to them eventually.)

I don't understand what "the permission dialogs are not merged for errors or revoking permissions", so a test case will help clarify the issue.

To quote Mark S Miller: “Specs traffic only in observable differences". Whether a UA decides to bundle UX prompts or not, isn't inherently observable in the JS API (except maybe through timing). I think that's desirable decoupling, and would like to understand what problem we're solving before changing the spec.

two more issues:
1/ (popup.jpg) the popup shows a microphone selection field on machines that don't have a microphone
2/ on linux at least there is a suggestion that it may be necessary to reload the page to get access. That doesn't seem to be true (which makes me happy). See eventuell.png (which also shows the cut-off german translation of it)

Deleted: popup.jpg 148 KB

	popup.jpg 148 KB View Download

Deleted: eventuell.png 47.4 KB

	eventuell.png 47.4 KB View Download

re (2) no it's not required for access, but I think that text was just added in order to reduce user confusion if any existing streams using old devices were still live.

Dominick, would you mind taking this or bringing someone else from the permissions team in to look at it?

+Permissions people. I currently don't have much bandwidth, but less confusion is definitely a good thing.

additional confusing thing: if the user changes the permission here, the camera icon continues to have a red 'x' until the next call to getUserMedia. enumerateDevices returns a string with a label before that even (which is great as it allows the application to detect the change in permission)

last point is according to spec, I think. Once the "can see labels" bit is flipped, it stays on until page is closed.

#24: yes. But when the "see labels" bit is flipped the red x should disappear too. Small details (-:

 Issue 692440  has been merged into this issue.