We have added the site and others to the mic allow list in settings and still get the message that it is blocked and does not work. 

Unable to reproduce the issue on chrome reported version# 71.0.3578.80 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.onlinemictest.com/microphone-test-in-adobe-flash/
2) Accepted flash plugin, mic is working as excepted
Note: Also tested the issue on latest chrome stable# 71.0.3578.98, unable to reproduce the issue.

@Reporter: Please find the attached screencast for your reference, try to test this issue on latest chrome stable# 71.0.3578.98 or by creating a new person with no apps and extensions in it and let us know if the issue still persists. You can download latest chrome from URL: https://www.chromium.org/getting-involved/dev-channel. Attached details of GPU. 

Thanks!

Deleted: 914398.mp4 7.5 MB

	914398.mp4 7.5 MB View Download

Deleted: 914398-GPU.pdf 145 KB

914398-GPU.pdf 145 KB Download

I watched your video and noticed you used a camera and mic. We are using only a mic headset. if we use the webcam with built in mic it does work. But a headset with mic either usb or TRS jack do not work. 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tried testing the issue as per comment# 5 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.onlinemictest.com/microphone-test-in-adobe-flash/
2) Clicked on ADOBE flash player icon, and clicked on Allow in permission pop-up
3) Didn't seen 'Allow' message for ADOBE flash player, seen blank page

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it in better way.

Thanks!

++ Attachment

Deleted: 914398.mp4 4.3 MB

	914398.mp4 4.3 MB View Download

It looks like we are not the only people having this issue. please see the link

https://productforums.google.com/forum/#!topic/chrome/tVz3mbIMvww;context-place=topicsearchin/chrome/chrome$2071$20microphone$20blocked

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm the head of support at a webinar provider that uses Flash and I can report that we are running into this issue as well. I'm posting here so that the Chrome support person can see others are still affected by this issue:

As the OP stated, Chrome is not allowing permission to use the microphone in these applications if there is no camera present. Even if you explicitly allow a site to access it from the chrome://settings page, or via the privacy menu in the address bar, without a camera, the site will always be blocked. A short video is attached showing the problem, as experienced in our platform:

We see that the reproduction attempts made in this thread they use a webcam and microphone, which will work fine. Please remove the camera and use a simple headset and you will be able to reproduce the issue every time.

My questions are:
Is this expected behavior with the latest update, and we will have to change our code to compensate? 
If so, do you have any recommendations on things to look for and change?
Is this a bug that will be patched?

Any advice would be appreciated. Thank you.

Deleted: ChromeMicBug_121418.mp4 1.6 MB

	ChromeMicBug_121418.mp4 1.6 MB View Download

Tried testing the issue on chrome version# 71.0.3578.80 and on # 71.0.3578.98 using Windows-10 where we have only access for Mic, but somehow unable to reproduce it. Hence routing this issue to Inhouse for further triaging it, adding TE-NeedsTriageFromHYD label to it.

Thanks!

Tested this on Windows-10, Linux Debian Rodete Desktop(with no camera and only microphone) on the latest stable 71.0.3578.98 and canary 73.0.3643.0 as per below test steps:

Steps followed:
===============
1. Opened https://www.onlinemictest.com/microphone-test-in-adobe-flash/.
2. Clicked the 'Get Adobe flash player icon' and 'Allowed' the page to run flash.
3. On good build 'Allowing' the access on 'Adobe flash player settings' dialog shows the 'line' and it moves when I speak. On Bad build page is blank when allowed the access on 'Adobe flash player settings' dialog. Attaching the screen-cast of good and bad behavior.

Considered C#3 behaviour for bisecting the issue and below is the result.

Last good build: 71.0.3570.0
First bad build: 71.0.3571.0

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/36f28038d708bc1976b0c975de0ea95c747fa58b..ac00a5f3b9ba87fe2b59ff66d9907c3fb56deb96

guidou@: Could you please take a look at this.

Thank you!      

Deleted: 914398_Actual.mp4 1.6 MB

	914398_Actual.mp4 1.6 MB View Download

Deleted: 914398_Expected.mp4 1.6 MB

	914398_Expected.mp4 1.6 MB View Download

Removing RBS label since the impact of this bug is reduced to flash request for audio/video where there is no webcam in the system.

Working on a fix that might get merged to 72 and 71, but not blocking 71 release on this bug.

The impact of this bug is NOT reduced to a flash request for audio/video where there is no webcam in the system.

You INTRODUCED the bug by what you did that you claim was to bring this back into spec.
Clearly, the conditions you claim must not be allowed, MUST BE allowed.  If you claim there is a spec that's being violated, then the SPEC ITSELF is flawed because it fails to consider standard operating conditions that are encountered in normal use.

jeffrey.hildack@gmail.com:
To answer your questions.
* Is this expected behavior with the latest update, and we will have to change our code to compensate? 

There is a behavior change that exposed a pre-existing bug.
The behavior change is that if you request video and audio, and video permission is denied and audio permission is granted, then getUserMedia() will fail. 
Before, you would get an audio track, which is against the spec. 
Unfortunately, this change exposed a bug in a separate, but related part of the code that manifests in some situations where there is no camera.
For example, in onlinemictest.com, the flash version hits the bug, but the HTML5 version does not.

* If so, do you have any recommendations on things to look for and change?
If you are not requesting both audio and video and expecting to get only audio, you shouldn't change anything in your application once we fix the bug.
A fix will be available shortly in Canary 73.

* Is this a bug that will be patched?
Yes, it is. And we plan to merge the fix back to 72 and 71.

barrycoupang@: It looks like your bug is different from this one.
There is nothing wrong with the spec. There is just a bug that affects some scenarios where there is no webcam installed and it will be fixed shortly.
If your bug is not related to having no webcams, it is a different issue.
Once the fix for this bug lands, test it anyway to see if things improve for the other bug.

barrycoupang@: Note also that this bug is strictly related to flash requests for audio when there are no webcams. If your bug has nothing to do with this scenario, then it's a different bug.

+Adobe folks for awareness.  "With the proposed fix for 71+, if an application makes two requests it will see two permission prompts (one for each request/device type) if the permission hasn't been previously granted." - Guido

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.

Bug:  914398 
Change-Id: Ic79102d69efb93f874295dcb5a2c6fa463fd67be
Reviewed-on: https://chromium-review.googlesource.com/c/1382271
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617858}
[modify] https://crrev.com/9695ac9fec245f1f303c991a86c61bc73e3ab39d/chrome/browser/media/webrtc/media_stream_devices_controller.cc
[modify] https://crrev.com/9695ac9fec245f1f303c991a86c61bc73e3ab39d/chrome/browser/media/webrtc/media_stream_devices_controller_browsertest.cc

Thanks for the head's up.  We're seeing a modest amount of traffic around this topic on our forums, just FYI.

Has this been pushed out yet?  What version n umber should this be?  Last Chrome version I'm seeing here when checking for an update is still 71.0.3578.98.

This will be available in an upcoming Canary M73. After verifying we will merge the change to 72 and 71.

chris.martin@glynnk12.org,  jeffrey.hildack@gmail.com: The fix is availiable in Canary 73.0.3646.0. Please try it and let us know how it goes.

guidou@chromium.org: I can confirm that audio now works in Canary 73 as expected after allowing a microphone access and then activating it our software. I see that the allowances for mic and cam are more separate, with cam permissions not even showing up if no cam device is connected.

Apart from some odd application flickering, which may be unrelated, I can say that your fix worked for us. Can you please keep us all updated here as to the release of this fix for Chrome 71 and 72? It would be greatly appreciated.

Thanks, and if any others have any news, I'd be interested to see how this worked for you.

Requesting merge to 72 based on independent verification in #25.

This bug requires manual review: M72 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Also requesting merge to 71.

branch:3626

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/be6c07a1380c2006d46eaa826573d9c544dd49a7

Commit: be6c07a1380c2006d46eaa826573d9c544dd49a7
Author: guidou@chromium.org
Commiter: guidou@chromium.org
Date: 2018-12-21 21:35:42 +0000 UTC

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.

Bug:  914398 
Change-Id: Ic79102d69efb93f874295dcb5a2c6fa463fd67be
Reviewed-on: https://chromium-review.googlesource.com/c/1382271
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#617858}(cherry picked from commit 9695ac9fec245f1f303c991a86c61bc73e3ab39d)
Reviewed-on: https://chromium-review.googlesource.com/c/1389115
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#507}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be6c07a1380c2006d46eaa826573d9c544dd49a7

commit be6c07a1380c2006d46eaa826573d9c544dd49a7
Author: Guido Urdaneta <guidou@chromium.org>
Date: Fri Dec 21 21:35:42 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.

Bug:  914398 
Change-Id: Ic79102d69efb93f874295dcb5a2c6fa463fd67be
Reviewed-on: https://chromium-review.googlesource.com/c/1382271
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#617858}(cherry picked from commit 9695ac9fec245f1f303c991a86c61bc73e3ab39d)
Reviewed-on: https://chromium-review.googlesource.com/c/1389115
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#507}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/be6c07a1380c2006d46eaa826573d9c544dd49a7/chrome/browser/media/webrtc/media_stream_devices_controller.cc
[modify] https://crrev.com/be6c07a1380c2006d46eaa826573d9c544dd49a7/chrome/browser/media/webrtc/media_stream_devices_controller_browsertest.cc

guidou@chromium.org: Just checking in on this issue. Will we receive a separate reply when the changes are merged with 72 and 71, or have the changes been rolled out already to 72? If it's the latter, then there is no change to the behavior and the bug is not fixed in 72.0.3626.28 released 4 days ago, or so. The bug still appears to be fixed in Canary.

Any updates would be helpful. Thanks!

The fix is not in 72.0.3626.28. It will probably be available in the next beta.
It hasn't been merged to 71 yet.

At the moment there is no plan for M71 stable respin. 
If change looks good in M72 beta, we can decide to take it in for M71 respin (if any). 

FYI, my tests show that, as of 1/7/19, this issue is fixed in the 73.0.3664.0 Canary release, but has not made it to the Dev channel 73.0.3642.0 release. A number of students using our software in classrooms are affected by this issue, and any info regarding when we can expect to see this fix pushed to the stable release would be appreciated. Thanks. 

The fix is now available in the Dev channel (currently 73.0.3664.3).
It is not yet available on the Beta channel, but should be available when a new beta is released. 

This is a critical issue currently for our school district.  I see that the issue is fixed for future versions however there is no solution (in Chrome) for us at the moment so I am adding this comment for reference.

 
We use a website called Read 180 which still uses flash.  It requires a headset with microphone to use.  No matter what there is no way to allow the microphone when the headset is connected.  If I were to use a webcam with microphone it works as it should.

We have had this issue for weeks and I have been scrambling to set up Chrome's Legacy Browser Support, however many of our students who use Read 180 would have trouble signing into the Chrome browser in order to get the Legacy Browser Support extension installed/added via admin console policy.  I thought to add the LBS extension, using the instructions provided in the link below, for our Windows machines through GPO so that the extension could install without the need for the students to login to the browser first.

https://support.google.com/chrome/a/answer/3062037?hl=en

I found that adding this registry entry to a GPO ends up overriding the Google admin console forced installed extensions setting and makes the LBS extension the only forced installed extension.  Now we are back to square one.  We really don't want our students using another browser without using LBS but it might be our only option until this is released to a stable update.

 mlametta@, are you seeing this issue on Chromebook?

In reference to the flash/microphone permissions issue, no, our chromebooks have not had this issue, only our Windows devices.  Our students use both PCs and chromebooks to access Read 180.  All of our chromebooks have cameras as well as microphones so that is probably why they work fine.  It might be after the fact now but this screenshot was a good indicator that something was interpreting camera vs microphone wrong.  There was a headset with mic connected but no camera, notice 'Camera blocked'.

https://drive.google.com/file/d/1KymJJcxjHymsuejih-zRb2fn5k0Gg3Zh/view

I know this question is out of the scope of this topic and I will look to proper support channels but should the ExtensionInstallForcelist Chrome policy be overriding the Google admin console setting?

I will second mlame...@trschools.com's comments.  Our school district also uses Read 180 and we are in the same boat.  Added that we have Windows machines, Chromebooks and Chromeboxes.  The Chromebooks don't run into the issue because they have a built in camera - though our Chromeboxes do not have cameras connected thus all are failing.

I have a test Chromebox that I have connected one of our standard headsets w/ microphone to and it failed as expected then I connected an external USB camera to the same Chromebox and the same headset works fine.

This bug is reproducible on all platforms in M71 if there is no camera installed.
Possible workarounds are to install a webcam (even a fake/virtual software-based webcam should work), or install the new beta 72.0.3626.53, which contains the fix and was released yesterday for Mac, Windows and Linux (please test to verify that it works).
Note that M72 Stable will be released shortly (see https://chromiumdash.appspot.com/schedule), so it is unlikely that there will be another M71 release, but if there is one it will include the fix.

mlametta@: I don't have enough context to provide a proper answer to your question about ExtensionInstallForcelist, but it won't fix this bug in M71. 

Confirmed working in the new Chrome 72 beta on Windows.  Our solution will be to push this out to the machines experiencing this issue and create a shortcut specifically for the Read 180 website on the desktop.  Thank you Chromium team.


Google Chrome	72.0.3626.53 (Official Build) beta (64-bit) (cohort: Beta)
Revision	98434e6cd182d68ce396daa92e9c6310422e6763-refs/branch-heads/3626@{#620}
OS	Windows
JavaScript	V8 7.2.502.19
Flash	32.0.0.114 C:\windows\system32\Macromed\Flash\pepflashplayer64_32_0_0_114.dll