New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 695440 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

"Always allow https://... to access your microphone" is not sticky.

Reported by jpivar...@gmail.com, Feb 23 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Enter https://vidyowebrtc.web.cern.ch/ in the address bar. Note that this _is_ HTTPS (443), not HTTP (80).
2. Page cannot load because it needs permission to use the microphone. Select "always allow" from the menu in the address bar.
3. Reload the page. It still can't load because "always allow" has reverted to "continue blocking." In fact, the website is listed in chrome://settings/contentExceptions#media-stream-mic as "Allow", yet it says "continue blocking" when you actually visit the page!

What is the expected behavior?
I expect that having the exception listed as "Allow" in chrome://settings/contentExceptions#media-stream-mic would mean that it would _not_ block when I try to load the page.

What went wrong?
Microphone blocks when accessing the page, revealing an inconsistency between the settings and the browser's behavior.

Did this work before? N/A 

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 3.18.0-13527-gc2f2230
Flash Version: Shockwave Flash 24.0 r0

It could be worth looking into the content of the https://vidyowebrtc.web.cern.ch/ page. They might be trying something tricky there that confuses Chrome.

 

Comment 1 by jpivar...@gmail.com, Feb 23 2017

In fact, exactly the same thing happens with hangouts.google.com!

Comment 2 by jpivar...@gmail.com, Feb 23 2017

Independent confirmation of this bug on StackOverflow: http://stackoverflow.com/questions/19181615/chrome-not-remembering-the-choice-to-allow-access-to-microphone/19183257#comment64598649_19183257

(Yes, my Linux is Ubuntu 14.04.5 LTS; there was no place to say that in the above form.)
Labels: Needs-Triage-M56
Cc: rbasuvula@chromium.org
Labels: Needs-Feedback
Tested in chrome # 56.0.2924.87 and Canary #58.0.3026.0 on Ubuntu 14.04 and not able to reproduce the issue.Please find the screen shot for your reference.

@jpivarski: Could you please let me know if i have missed anything and if possible, Please create new profile without extension and apps.Re-check once and let us know the observation of the issue which would help us to triage the issue further.

Thanks in Advance.
695440.png
89.2 KB View Download

Comment 5 by jpivar...@gmail.com, Feb 28 2017

I confirm that we're using exactly the same version number and build of Chrome from your screenshot, however, I never get the "vidyowebrtc.web.cern.ch wants to..." dialog box on the left. So I'll include extensive screenshots below.

First, I created a new profile with no extensions. (You can see that the name is "AlienHead" in the corner, from the icon.) Then I visited vidyowebrtc.web.cern.ch. Nothing pops up, but I found the microphone-blocking icon in the corner and clicked on it to raise the dialog box on the right (step1.png). I selected "Always allow" (step2.png) and clicked "Done."

Then I reload the page and see that the dialog is back to "Continue blocking microphone access" (step3.png). I can repeatedly set it to "Always allow" and reload, and each time it goes back to "Continue blocking."

If I check the microphone settings (step4.png), I see that vidyowebrtc.web.cern.ch is in the list of allowed sites. Chrome has apparently stored this setting, but it doesn't follow through when I visit the site.

Until I saw your screenshot, I had never noticed the dialog box on the left. If I click on "Secure" (step5.png), I see a list of permissions, from which I have chosen "Microphone" and "Camera," which prompted me to reload the page. After the reload, they're still listed as "Allow" on the left dialog box, but not on the right dialog box.

I wonder why my dialog boxes look different from yours. We are definitely using the same version number and build of Chrome.

step1.png
70.3 KB View Download
step2.png
73.7 KB View Download
step3.png
70.3 KB View Download
step4.png
146 KB View Download
step5.png
94.3 KB View Download
Labels: -Needs-Feedback
Thanks for feedback. Removing "Needs-Feedback" label.
Cc: krajshree@chromium.org
Labels: Needs-Feedback
Unable to reproduce the issue on Ubuntu 14.04 using chrome reported version #56.0.2924.87 and latest dev #58.0.3025.5

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to https://vidyowebrtc.web.cern.ch/
2. Clicked on "allow" button for using microphone.
3. Observed that the page loaded without any issues.

jpivarski@ - Could you please check this issue using latest dev #58.0.3025.5 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!
695440.ogv
5.1 MB View Download
Wow, that is clearly the same version number and it is clearly working for you in a way that doesn't for me. I never see the "Allow/Block" dialog box on the left, for instance.

Since it's not the executable, I checked the files in ~/.config/google-chrome for permissions issues. They're all owned by me.

I don't actually know how I'd install a different version of Chrome (I get it through Ubuntu's packages), much less isolate it in a way that wouldn't affect my working version.

Therefore, I think I'm going to have to give up on this for now. If I get any news that might be relevant, I'll post it here.

Project Member

Comment 9 by sheriffbot@chromium.org, Mar 1 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I think I noticed the key difference: in your video, the microphone-choice drop-down menu is set to "Default." Mine (see step1.png) is greyed-out as "None available."

Somehow, Chrome isn't picking up on the fact that my computer has a built-in microphone (other apps use it) and the radio button reverting to "block" rather than "allow" is arguably intentional. Where should I start looking to learn how to point chrome to my microphone (the CRAS device)?

Components: Blink>GetUserMedia>Mic
Labels: -Needs-Triage-M56 M-59 OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Win-7 and Win-10 using chrome reported version #56.0.2924.87 and latest canary #59.0.3035.0.

Issue is not seen in Linux-OS and Mac-OS.

This is a non-regression issue as it is observed from M35 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!
Labels: -OS-Linux
Owner: hta@chromium.org
Status: Assigned (was: Untriaged)
Harald: is your team owning the permissions pieces? Can you assign this to someone to look at?

Comment 14 by hta@chromium.org, Apr 5 2017

Owner: guidou@chromium.org
This is a UI bug that happens when there are no microphones or cameras. The issue appears to be fixed in M58.
Status: Fixed (was: Assigned)

Sign in to add a comment