siva.a.shankar@ - Thanks for filling the issue...

As per the original comment, the issue is specific to Mac Mojave. 
As we don't have that particular Mac OS to test and confirm the issue from TE end, requesting the appropriate team to look into the issue and help in further triaging..

Thanks...

 Issue 885183  has been merged into this issue.

ellyjones: Seems this is an issue with the interaction between Mac OS's camera permission and Chrome's permission, could you take a look (and reassign if appropriate?) Thanks!

The microphone permission also problematic, there is no error thrown if the user has rejected microphone access, it will just give empty sound stream

mac triage: over to avi@, who is on point for the 10.14 permissions flow.

Poking this one, specifically for the microphone side of things. Is the permissions check something that we can/have to trigger manually from within Chrome in Mojave? I was under the impression the OS would somehow deal with that.

If it is, then we need to do so. Mojave is rolled out enough that it should be straightforward to test. If it isn't, then we need to figure out why Chrome is marked as without that permission - perhaps something goes wrong during the macOS upgrade? 

In Mojave, the OS will now *always* mediate access to protected resources; there is no auto-granting of the permission. The OS prompt is one-shot at the time of accessing the resource, and users can grant access later in System Preferences. Apps can query and request permission in a flow that is separate from trying to acquire the resource for the first time. More info here: https://developer.apple.com/videos/play/wwdc2018/702/

Thanks for the link!

For audio, it seems like we could plug in a call to AVCaptureDevice::authorizationStatusForMediaType() without too much hassle, and fail early, rather than creating an audio stream that's just silent. I guess that would require us to pull that in weakly, considering it's part of the 10.14 SDK.

Yes, something like that would work. The new way to handle future-SDK things is to use the |if (@availalble(macOS 10.14, *))| syntax, which handles some of the old complexity with weak linking.

 Issue 921480  has been merged into this issue.

Bumping this bug up a bit: the audio team have gotten several reports of the microphone just silently not working on macOS Mojave, all solved by having the user go into System Preferences and ensure that Google Chrome has the right permission.

IMO, there needs to be some UX in place to inform the user that Chrome is not allowed to read the Microphone / Camera when a that hasn't been blocked in Chrome asks for Microphone or Camera. Is this the right bug to track that work?

For audio, I could add a check like in #11, where we'd just fail earlier if we don't have permission, but it's possible it would create timing issues. It also doesn't actually help the user get audio working, just makes it more obvious when it's not working.

While testing with Chrome 71.0.3578.98 on Mojave 10.14.2 I noticed that on refresh an error IS thrown (NotReadableError).

In my experience, the only time the error is NOT thrown is the 1st time the browser asks for OS level permissions and you deny them. If you refresh you get a proper NotReadableError.

I was able to replicate the issue with the JSFiddle in the initial bug report https://jsfiddle.net/r60bzmrs/ , with this CodePen listing getUserMedia() errors https://codepen.io/naicuoctavian/pen/wPeZWO and with the production video recorder at https://addpipe.com

FFox 64 always throws an error: when you're 1st asked for the OS level permission and you deny AND on refresh (after denying).

The error thrown by FFox is NotFoundError. 

To clear the OS level permissions use these Terminal commands:
tccutil reset Camera
tccutil reset Microphone