I have built an ember music app consuming favorite songs by SoundCloud using the api of this project. You can see the demo here
From a couple of days i have noticed that only in Chrome any song i play, the sound and and the stream do not work, in the other browsers ( Safari and Firefox) it works well as usual.
I thought at the beginning it was violating the content Security Policy directive in environment Ember Cli. See the question here but although i have solved it, the problem is still there, plus there is not console log error
These are all the actions i have taken in Chrome to fix it, none of them was successful
Removed any chrome extension
Clear cache and deleted cookies
Tried in incognito mode
Reinstalled Chrome
My chrome is update , the version is 48.0.2564.116 (64-bit)
At the moment the sound and the stream do not work in my app and also in the demo http://soundcloud.lrdiv.co/ but in all the other browsers yes.
So question is, what other actions can i take? Should i maybe downgrade a Chrome Version as last try? Is it only a browser problem?
I have also followed these instructions with not solution
Found the solution here: https://github.com/soundcloud/soundcloud-javascript/issues/39
If you deactivate the flash here chrome://plugins/ it works out
Related
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!
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 :)
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.
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.
I'm building a web app with offline capabilities and it doesn't appear that Chrome (iOS) clears localstorage properly. I've cleared all the data in the settings but it keeps using the first version that I tested with.
Clearing the data works fine in Safari so it appears it's an issue with Chrome.
Does anyone know if this is a bug with Chrome on the iOS and localstorage? I'm only using the manifest file at this point.
Thanks for any help or pointers.
You are using mainfest, that means you are using application cache. So have a try https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache#Storage_location_and_clearing_the_offline_cache
Or you could modify manifest file to force the browser update the page. By the way local storage is different from application cache.