Chrome browser camera denied access

Report · Dec 12, 2018

Hello.

After updating to Chrome version 71,

I can not use the microphone because the microphone is blocked when I use the flash player to recognize the microphone.

If you allow it in Chrome settings, it will still be rejected.

If you have users with the same symptoms, please share your information.

The computer specification is Windows 7 (32 bit)

Report · Dec 17, 2018

Hello

I have the same problem.

I use Adobe Connect.

The microphone is not activated.

Chrome v 71.

Please ad a solution.

thanks

Report · Dec 18, 2018

For the Connect issue, I don't think it's the same, although if you're using an on-premise Connect installation that's not configured to use HTTPS by default, that would definitely make sense.

For Connect, the optimal solution is to use a current version of the actual Connect add-in. If you need to use "classic" mode where just Flash Player is running in the browser, that appears to work. I tested it against our Connect issue. I had to enable permissions for the Camera, Microphone, Flash and for Redirects and Pop-Ups before it would launch, and because Chrome is making it more and more difficult to use Flash Player in the browser, that experience is guaranteed to become more painful for your end-users over the coming months.

If you're responsible for managing your on-premise Connect installation, I'd recommend that you start talking to the Connect team about how to achieve optimal results as we continue down the path of sunsetting Flash.

Thanks!

Report · Dec 18, 2018

Chrome requires that you serve all of the content on the page over HTTPS as a prerequisite for accessing the camera and microphone. It sounds like that's what you're running into. Enable HTTPS by default for your properties if you want them to continue to work on Chrome.

Report · Dec 19, 2018

My web site has HTTPS.

I have Adobe Connect.

mic & Web blocked by default.

Report · Dec 19, 2018

At the very least, Chrome is doing the blocking. There's not anything we can do about it.

I'm also pretty confident that your content fails to meet one or more of the prerequisites that Chrome enforces for microphone and camera access. The most obvious one is HTTPS, but there are others. The console or security tab in Chrome developer tools might give you some clues.

Since you're a paying Connect customer, you may want to contact Adobe's support team. If this is a widespread issue for Connect, I'm sure that they know about it and would probably have a workaround.

Contact details for the Connect support team are below.

Enterprise Support

Report · Dec 19, 2018

I think I know what's going on now. It's a functional regression related to Chrome. It looks like if you don't have a camera available, requesting the Microphone will fail.

There's no workaround from Flash. A future Chrome update will fix it.

Here's the Chrome but:

914398 - Mic not working using flash plugin - chromium - Monorail

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/9695ac9fec245f1f303c991a86c61bc73e3ab39d

commit 9695ac9fec245f1f303c991a86c61bc73e3ab39d

Author: Guido Urdaneta <guidou@chromium.org>

Date: Wed Dec 19 16:49:09 2018

Fix media-device permission handling of OpenDevice Pepper requests

Prior to this CL, all Pepper OpenDevice request were treated as if

they were requesting both audio and video in terms of requesting

permissions.

When crrev.com/596698 landed, it changed general permission handling

to comply with the Media Capture and Streams spec, which states that

requests for audio and video should fail if permission for one of

the device types cannot be obtained. Prior to crrev.com/596698, requests

succeeded and returned a track for each authorized device types, and

no tracks for unauthorized types.

This broke Pepper requests for audio when there are no webcams in the

system. The reason is that the pepper requests were treated as requesting

both device types, but if there is no webcam, the corresponding

permission is blocked due to lack of hardware.

This CL fixes that by treating Pepper requests similarly to

getUserMedia() requests, where permissions are checked only for device

types that are requested.