Google Chrome Microphone problems. No joy whatever the settings - google-chrome

I've been getting annoyed from this. It was used to work fine, but it must have happened with some recent update.
I'm on Google Chrome 71 and the microphone doesn't work. Regardless the extension (including Google Meet) and the settings which clearly shows the microphone as active, the audio is not passing sounds in.
The audio settings at computer level are fine, the chrome settings are fine and the microphone is enabled and whitelisted for the given site.
I tried also to fully reset the browser, restoring to the original settings and to use unlinking my accounts. No joy.
Conversely, while using Chromoium (Google Canary) everything works fine.
Has anybody experiencing the same or found a solution?

Ok, in a nutshell - and after having reported this to their chrome bug center - it turned out to be an issue I (and very likely many other users) have been experiencing with the upgrade to MoJave.
Basically, the upgrade seems to remove the microphone access at OS level.
To fix/check this, go into System Preference > Security and Privacy > Microphone and re-instate the check to Google Chrome, which should in theory unticked as it was on my case.

Related

Third-Party Cookies in Chrome

On the latest version of Chrome (Version 90.0.4430.85 on MacOS), I found that third-party cookies are disabled even though in my browser settings I checked "Allow all Cookies". I also tried adding the site to "Sites that can always use cookies" and checked "Including third-party cookies on this site", but it still doesn't seem to work. I'm accessing a course on LTI that requires third-party cookies. (The course is quite old so that might be an issue)
I'm getting this error:
Chrome Settings:
The reason I know this is because my other laptop has an earlier version of Chrome(around 80) and the cookies are working(the course loads), but it no longer works when I update my Chrome to the latest version.
When I tried in Safari, I'm able to allow third-party cookies by disabling "Prevent cross-website tracking", but I cannot find such settings in Chrome.
Any ideas on what I might try to be able to use third-party cookies on the latest version of Chrome? Also, why is it the case that this site functions in an earlier version of Chrome but not the latest? Thanks in advance.
Your browser settings for 3rd-party cookies look OK as far as testing by allowing all.
The issue may be with the LTI tool/app provider who is providing their product through Canvas and other LMS's - for example, if the LTI tool/app provider hasn't set their cookies with SameSite=None - sounds like you're suspecting that as far as course/app being older.
I think you can test this by temporarily disabling the same site requirement here: chrome://flags/#same-site-by-default-cookies
There are a few other decent testing tips from Chromium here.
If that's the issue and you still need to provide access quickly for a bunch of users, but can't wait for the LTI tool/app to be updated, you can usually update the LTI app/tool settings in Canvas to open it in a separate tab/window instead of as an iframe - e.g. these settings in Canvas.
Hope it works out!

Cloud Shell: Editor is not loading in incognito mode

So I have been following the following step for past few months:
Log in to Google Cloud Console from Chrome's incognito mode
Activate Cloud Shell
From there, I usually opened Editor and managed my files in a new window
Today while I was following the above steps, this issue raised up:
Basically, I cannot open editor anymore. I have already went through similar posts, and my issue is that I am using incognito where browser extensions or cookies shouldn't be an issue.
I am facing this problem for the first time and if anyone knows what is the cause or any suggestions would be appreciated.
EDIT:
For now Microsoft Edge InPrivate Mode is working for me. I am still interested in fixing the issue for Chrome.
Have reported the issue in Issue Tracker. Please "start" for more attention.
This started happening recently because third-party cookies stopped being supported in Incognito mode as of Chrome 83. Third-party cookies are required for the editor to work because of the way the open-source Theia IDE is integrated into Cloud Shell. The team is exploring various fixes, but in the mean time the following workaround should work:
In Incognito Mode, click on the crossed out 'eye' icon on the address bar.
Click on 'Site not working?'
Click on 'Allow cookies'
Safari problem stems from the same issue, but I am not certain if a similar workaround exists.
I've encountered the same issue myself (I tried this on Chrome running on both ChromeOS and MacOS) - it looks like a bug so in this case I'd recommend reporting it on Google's Issuetracker (you can even put a link to this post).
UNfortunately it looks like it's not just the Chrome browser. I tried this on Safari 13.1 and found the issue you described is also present.
I didn't check other browsers but IssueTracker is the way to go. And be patient :)

Chrome - Microphone blocked even if it shows allowed

I am trying to implement and use the Chrome Speech API on my website but I'm not able to do it. The response I receive is that the "Permission to use microphone is blocked" but it really isn't. Microphone settings in Chrome are clearly showing that I don't have sites blocked and that the system should it least ask.
It is not a problem with the website because I have performed tests on other computers and it is working fine. I would like to figure out the settings/preferences that need to be readjusted in order to make this work.
In addition to this, in C:\Users\MY-USER\AppData\Local\Google\Chrome\User Data\Default\Preferences I was able to see entries for my site and I removed them but nothing changed. I tried also (not in order:
1- Reset Chrome.
2- Uninstalling/reinstalling Chrome. Manually removing files and registry entries.
3- Run Chrome in incognito mode.
4- Run ChromeCleanup Tool
5- Not working on Chrome Canary.
6- Every computer was tested on the same internet connection.
I am not sure what else I can do about this.
Thanks!

How do I fix the "we can't reach this page" error or "err_connection_timed_out" on my browsers?

I am currently experiencing an error everytime I use my Microsoft Edge. Whenever I try to go to a site, I always end up with this error. The weird thing is, this issue only happens on certain websites (such as Facebook and Yahoo currently) and sometimes with Google. It likes to disconnect me often and I really don't want to have to deal with this issue anymore.
My internet works fine as my laptop (which I'm currently on) and phone can connect to it without issue. I don't know why it doesn't work on my desktop especially since its internet is Ethernet.
I tested this on other browsers to see if it was only on Edge but it turns out that chrome and firefox experience the same issue with different sites as well. For all three, I haven't been able to go on Facebook and Yahoo, and sometimes Google.
I know the problem is from my end because clearly, the sites are up. Is there any way to solve this or has anyone else found a solution to this?
I'm running Windows 10.
I've tried the following:
ipconfig / flush
ipconfig / reset
ipconfig / release
ipconfig / renew
clearing caches and browsing history
a full scan for malware using malwarebytes and windows defender, already removed/quarantined all threats, did this multiple times to ensure there were none left
reinstallation of chrome and firefox and a reset of edge
ipv4 - changing preferred and alternate dns address to 8.8.8.8 and 8.8.8.4 respectively
checked to see if a proxy was up, no proxy
If I were to do a factory reset, would this solve the issue?
To narrow it down a bit, can you confirm that you only get this when navigating to the sites listed and they're using SSL / HTTPS? Some will auto re-direct to HTTPS if you go to their non-SSL equivalent, but it's worth trying this on sites like Google which do support both.
If this does help narrow down the behaviour, then I've seen this behaviour once before, but this was behind a corporate proxy which didn't support SSL SPDY.
You can try disabling SPDY support, but there is likely to be an underlying issue (perhaps anti-virus acting as a proxy?).
To test disabling SPDY:
Internet Explorer 11
In the browser, select Tools > Internet Options > Advanced > HTTP
Settings and clear the Use SPDY/3 option.
Firefox
In the browser, enter about:config in the address bar and press
Enter. Confirm the security warning. Type
network.http.spdy.enabled in the Search field. For all the entries, set the Value to false.
Chrome
Use a switch to disable SPDY for Chrome. Edit the shortcut for Chrome
and add the following switch at the end of the Target path:
--use-spdy=off
For example, if Chrome's default shortcut link is pointing to
"C:\Program Files\Google\Chrome\Application\chrome.exe", change it to
"C:\Program Files\Google\Chrome\Application\chrome.exe" –use-spdy=off.
Source:-
http://bluecoat.force.com/knowledgebase/articles/Solution/HowtodisableSPDYprotocolsupportinbrowsers
I had a caller who was getting the "can't load page" error in Chrome only when logging into the AMEX site. Every other browser worked. The fix was to disable some weird experimental Chrome setting that is on by default. Go to chrome://flags, search for "experimental quic protocol" and "Disable" it.
Source
Click on start/control pane/IE options/Privacy Tab/Sites
Look at list of sites to see if any Google sites are blocked.

Chrome v45 and ShellinABox

We have a web application that runs within a VPN. It has a self signed cert on it and is accessed through the server's IP address.
Part of the functionality of this app are some legacy Java apps (that no longer run in Chrome). Our initial work around for our Chrome users was to run Shell In A Box within an iframe of the web app to run those. All was good until the latest version of Chrome, v45.
What we’re seeing is that appears to be blocking the iframed content (maybe because of the self-signed cert?). If we grab the ShellinABox URL and drop it in a new tab, it works as it used to in the iframe. If we go back to the iframe, it now works. If we close Chrome and open it back up, it still works.
I should also note that we tried the canary builds as well. It's up to v47.x and we still see the same behavior there. We were reading through some of the Chrome group/bug lists and saw some reports that were similar but the "fixes" supposedly going through canary still didn't resolve it.
So, it appears that an exception is being logged somewhere. Does anyone have an explanation for this behavior and is there a way to set this exception without jumping through those hoops?
It turned out it was due to a permissions issue with ShellInABox that didn't reveal itself until v45 of Chrome, for some odd reason.