We Keep Coding

Chrome: Notifications not working, permission not requested

I have been struggling for hours on trying to enable notifications on chrome, on firefox it works perfectly and it works ok as well on localhost url address. But when it comes to non-localhost url address it just doesn't work.
i have been checking on the permissions that are displayed left next to the url input box where you see the website's information and it shows that notifications are permitted, but on advanced settings it shows block with a message "Blocked to protect your privacy" and i am not entirely sure what does that mean.
the code i am trying to execute first is simple:
if(Notifications.permission == "default"){
Notification.requestPermission()
.then(permission => {
console.log(`Permission given is: ${permission}`);
});
}
else{
console.log("Notification permission is: ${Notification.permission}`);
}
The result of this code is Notification permission is: denied meaning that else statement was executed but permission is given as if permission was already requested and denied was the answer of the request.
Can someone explain why does this happen?

I figured out that the problem was comming from loading the website with no TLS https, making some features in chrome to be disabled by design..
I was unabled to figure this out sooner because the host testing i was using was being accessed with 0.0.0.0 instead of localhost which is the one that chrome whitelists for features

Cordova Geolocation returning empty

This is repeat of
Apache Cordova GeoLocation not providing data
Following code returns an empty object:
function onDeviceReady(){
$cordovaGeolocation.getCurrentPosition({}).then(function(resp) {
console.log(resp);
$scope.geo.get = resp;
});
}
No errors or anything, just empty {}
Update 1
Works fine Samsung S3, but doesnt work on Nexus 4.
Update 2
LogCat shows the following line:
Caught security exception registering for location updates from the system.

You need to make sure that you added the corresponding location permissions.
If you are using iOS, it might ask you if you want to allow the app to determine your location.
If you are not sure, check the settings on both devices (android/ios) to check the requested permissions.

Why is getUserMedia throwing a [object NavigatorUserMediaError] when I click "Allow" in Chrome?

Recently, I started getting errors when trying to access the client's mic through my website. When Chrome asks whether to allow the site to access the user's microphone, [object NavigatorUserMediaError] is produced whether they click "allow" or "deny." This has been happening regardless of whether or not a microphone is actually plugged into the computer (which is running Ubuntu 12.04).
Further testing through Firefox showed that this is not specific to Chrome. The problem only started after I had done a live-input demo and then logged out of the computer. I tried making a bare bones demo of accessing the microphone, and it ran into the same problem.
var getVideo = false, getAudio = true;
navigator.getUserMedia || (navigator.getUserMedia = navigator.mozGetUserMedia ||
navigator.webkitGetUserMedia || navigator.msGetUserMedia);
function init() {
if(navigator.getUserMedia) {
navigator.getUserMedia({video:getVideo, audio:getAudio}, onSuccess, onError);
} else {
alert('getUserMedia failed.');
}
}
function onSuccess() {
console.log("Yay");
}
function onError(err) {
console.log("Noo " + err);
}
This is rather puzzling as it had worked perfectly up until the point where I logged out and then logged back in and tried to test it again.
I am hosting the web code locally, through Jetty and Eclipse. I am accessing it by typing localhost:8080/my-program into the web browser.
Edit:
After the error occurs, the icon of a camera shows up in the chrome address bar, saying that Chrome is accessing my microphone and listing two possible microphones, "Default" and "Built-in Audio Analog Stereo."
Edit 2:
This error is also occurring on other websites that try to access my microphone through webrtc. Traditional Flash implementation still works.
Chrome seems to be throwing out an error message at regular intervals while open.
[361:362:0725/095320:ERROR:audio_output_device.cc(186)]
Not implemented reached in virtual void
media::AudioOutputDevice::OnStateChanged(media::AudioOutputIPCDelegate::State)
Edit 3:
I was able to clarify the error message a bit more
NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}

** One Browser at a Time **
I've encountered this situation when I am testing with multiple browsers open. It would appear that only one browser can access the media at a time.
ie When I've got my page open in Chrome, and the video/audio is working, then Firefox won't work, and when I've got it working in Firefox, then Chrome doesn't work.

This can happen in two situations and I've experienced both in Ubuntu 12.04:
You have clicked Deny once and then the browser saves that setting, always returning error when asked for media access in that page. (This does not seem to be your case as you get the question from browser, but you just have to go to the address bar, click in the camera icon and change the option to ask again).
Your browser is not having access to the media devices and as in any computer without cameras nor microphones, even if you press Allow, you will get an error event as it cannot give you any streams. Try to check the browser settings to see if you can choose the selected camera. I've experienced this and the list was empty. To solve this I had to reboot the machine and Chrome started showing the list of devices again.

NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}
This means your browser settings are not allowing you to access the camera. Go into your browser settings -> under website settings you'll find a list of webpages that you have blocked from accessing your device.

getUserMedia only works on https; no exception for localhost (i.e http://localhost). Safari also does not ever seem to allow getUserMedia from within an iFrame. I always get a “Trying to call getUserMedia from a document with a different security origin than its top-level frame” error. This makes using sites like codepen and jsfiddle impossible.
More detials https://webrtchacks.com/safari-webrtc/

Microsoft JScript runtime error: Access is denied Dropbox.js in IE

<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/dropbox.js/0.9.0/dropbox.min.js"></script>
Hi am using above file to access dropbox functions. It contain all the dropbox functions. i included this one to my application and i
used the below code to upload a file to dropbox using writefile function.
This was working fine in chrome and Mozilla browser but in IE its getting an error.
The error is: "Microsoft JScript runtime error: Access is denied".
Please anyone help me how to resolve thid IE Error and tell me the reason why this error coming only for IE Browser?
var UploadToDropbox = new Dropbox.Client({ key: consumerKey, secret: consumerSecret, token: accessToken, tokenSecret: accessTokenSecret, dropbox: true });
UploadToDropbox.authenticate(function (error, UploadToDropbox) {
if (error) {
alert('Something wrong here.');
}
else {
UploadToDropbox.writeFile("HelloWorld.txt", "Hello, world!\n", function (error, stat) {
if (error) {
return showError(error); // Something went wrong.
}
alert("File saved to your dropbox successfully. ");
});
}
});
Hi thank you for your reply my question and i tried like that but still that same error coming.
Ok now what should i do for resolve this error.
and i tried with this also
<script type="text/javascript">
// Hack to make dropbox.js works in IE8, IE9.
if (!window.btoa) window.btoa = base64.encode;
if (!window.atob) window.atob = base64.decode;
</script>
but same error.

Open IE->Tools-->InternetOptions
In Security Tab->select Zone as Internet-->Click Custom Level Button---> Check "Enable" in Access data source across Domains under Miscellaneous.
It seems that IE does not play well with javascript events that trigger a DOM control. So try to remove such event actions , if they are present .
Usually means that you are attempting to update a property or access content that is not permitted under your current security settings.
Sometimes, it also happens due to usage of deprecated method .

The hack in your question is not necessary. dropbox.js packages its own implementation of atob / btoa, which is used on IE <= 9. You can try it out by accessing Dropbox.Util.atob and Dropbox.Util.atob in the IE Developer Tools console.
base64 code: https://github.com/dropbox/dropbox-js/blob/master/src/base64.coffee
First, please run the checkbox.js sample code to check your IE settings. If the sample works (you can log in, add tasks, mark them as done and remove them) then your IE settings are OK, and the problem is elsewhere.
checkbox.js: https://dl-web.dropbox.com/spa/pjlfdak1tmznswp/checkbox.js/public/index.html
Second, make sure that you're serving your HTML page using https://. The Dropbox API server uses https, and IE <= 9 doesn't allow cross-domain requests from http pages to https servers.
Third, you shouldn't need the token and tokenSecret parameters in the authorize call.
If you still get the JScript runtime error, can you please point to the line of code that causes it? Also, consider opening an issue on the dropbox.js GitHub page. This will get faster responses.

Access Denied for localstorage in IE10

Yesterday I installed Windows 8 and am now trying to understand why I am getting an "Access Denied" message when accessing localstorage. The page is being served on the same PC with the browser (http://localhost). My feeling is that one of the security settings in IE 10 is wrong, but I haven't figured out which one.
The line of JavaScript code triggering the error is:
if(window.localStorage.getItem('phone') == null)
The code works fine in the latest version of Chrome.

Our users were having issues with web sites using the LocalStorage feature (including Twitter) on Windows 8 with IE 10. When accessing one of these sites with the F12 Developer Tools open, a SCRIPT5: Access is denied message appeared on the console.
After working with Microsoft support, we identified the cause. It turned out to be a problem with the settings on the C:\Users\username\Appdata\LocalLow folder in their user profile.
Each folder on your computer has an integrity setting. More information about the purpose of this setting is here: http://msdn.microsoft.com/en-us/library/bb625964.aspx
The integrity setting on the AppData\LocalLow folder (and its subfolders) in each user's profile is supposed to be set to "Low" (hence the name). In our case, the integrity level was not set correctly on this folder. To rectify the problem, run the following command in a command prompt window:
icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L
(If there is more than one user account on the computer and the other users are having the same issue, the command needs to be run under each affected user's account.)
As for how this setting got changed in the first place? In our case, it was caused by a problem in the customized Windows 8 image we deployed to our workstations. For others that are having the issue, my research has revealed that the use of a "system cleaner" utility may be to blame.

Doubtless there might be many causes of the same symptoms, but here is what fixed this issue for me.
I had just one of many Windows 7 PCs with IE11 exhibiting the symptom of "Access Denied" on attempting any JavaScript involving window.localStorage from otherwise reputable and well-behaved web sites. Use of Process Explorer revealed that the proximal cause was an ACCESS DENIED when taskhost.exe (acting on behalf of Internet Explorer) tried to open DOMStore\container.dat for Generic Read-Write. In fact, it was worse than that: if I deleted container.dat, the same ACCESS DENIED occurred, even through the file did not exist any more. And, if I deleted the (hidden) DOMStore folder, when taskhost.exe attempted to recreate it, that received ACCESS DENIED as well.
After two days of chasing false leads, the final solution was this:
The registry entry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore\CachePath
(do note the LowCache in that string) was incorrectly set to:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
when it should be:
%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
with the consequence that low-integrity localStorage requests were being directed to medium-integrity regions of AppData disk storage, thus generating ACCESS DENIED errors, and killing the use of JavaScript window.localStorage.
This registry entry must have been wrong for many years: perhaps a side-effect of enthusiastic take-up of buggy platform previews and so on. This error survived a total removal and re-installation of IE11.
There is a similar-looking registry entry for the medium-integrity cache:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\DOMStore\CachePath
and that is correctly left as:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
and should not be changed.

Try enabling the Enhanced Protected Mode in the IE settings, under the Advanced tab, in the Security sub-list. This enables the Microsoft XSS filter. I had similar issues when logging into SE, and fetching google+ notifications, and my first workaround was starting IE with admin privileges. But I think the EP mode will do the trick in your case too.
Related links: Understanding Enhanced Protected Mode

Mark Russinovich always says: "when in doubt, use Process Monitor":
localStorage data gets stored in XML files in the following folder:
C:\Users\[USERNAME]\AppData\Local\Microsoft\Internet Explorer\DOMStore
A profile of the file activity while reproducing the issue can tell you if the problem is caused by missing file access permissions or maybe even an anti-virus program.
I can reproduce the error by adding the read-only attribute to "DOMStore\container.dat". You should check if all file/folder permissions and attributes are set correctly. On my machine, admins and my own account have full permission for the mentioned folder.

Go to Tools/Internet Options/Advanced and under 'Security' select 'Enable DOM Storage' checkbox. This should fix the problem

I added the websites involved to the Trusted Sites section of IE and have not received the error again.

In addition to the already excellent answers here, I'd like to add another observation. In my case, the NTFS permissions on the Windows %LOCALAPPDATA% directory structure were somehow broken.
To diagnose this issue. I created a new Windows account (profile), which worked fine with the localStorage,so then I painstakingly traversed the respective %LOCALAPPDATA%\Microsoft\Internet Explorer trees looking for discrepancies.
I found this gem:
C:\Users\User\AppData\Local\Microsoft>icacls "Internet Explorer"
Internet Explorer Everyone:(F)
I have NO idea how the permissions were set wide open!
Worse, all of the subdirectories has all permissions off. No wonder the DOMStore was inaccessible!
The working permissions from the other account were:
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
my-pc\test:(OI)(CI)(F)
Which matched the permissions of the parent directory.
So, in a fit of laziness, I fixed the problem by having all directories "Internet Explorer" and under inherit the permissions. The RIGHT thing to do would be to manually apply each permission and not rely on the inherit function. But one thing to check is the NTFS permissions of %LOCALAPPDATA%\Microsoft\Internet Explorer if you experience this issue. If DOMStore has broken permissions, all attempts to access localStorage will be met with Access Denied.

This issue may also be caused by having missing or corrupted registry entries. If a reset does not resolve the issue, the LocalLow folder has the correct integrity level, and the DOMStore registry value is correct, run the below commands to re-register IE in the profile:
32 Bit OS:
C:\WINDOWS\system32\ie4uinit.exe -BaseSettings
64 Bit OS:
C:\WINDOWS\system32\ie4uinit.exe -BaseSettings
C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings
See the IE MSDN blog for more details.