Whenever a machine with IE9 located in our corporate domain goes to the website (via the link), we get the "Permission denied" dialog box when accessing any of the following window properties (styleMedia, clientInformation, screen, history, navigator, localStorage, performance, sessionStorage). The initial loading of the pages works, but when you have a link to the same page, an error occurs.
This initially manifested itself when loading the jQuery library. The first time jQuery accesses window.navigator.userAgent, a permission error will be resolved.
All our machines are Windows 7 64-bit Enterprise SP1. The code below can be run from IIS or directly open the .html file.
We cannot reproduce this problem outside our corporate domain. We suspect some kind of policy in our corporate environment, but could not determine which policy is causing this problem.
We can mitigate the problem as follows:
- Switching to IE7 or IE8 document mode and then back to IE9 standards Document mode puts the browser in the state in which it will work from now on.
- Updating the page fixes a one-page download, but the problem will be repeated when the link is clicked, and the other page (maybe the same as you are now) is loaded by the link.
- Go to the site from a computer outside our domain.
test.html
<html> <head> <title>Permission Denied</title> </head> <body> <a href="test.html">Click Here</a> <script type="text/javascript"> alert(window.navigator); </script> </body> </html>
To view all inaccessible properties, we can open this html and click the link on the page:
testWindow.html
<html> <head> <title>Permission Denied</title> </head> <body> <a href="testWindow.html">Click Here</a> <script type="text/javascript"> var deniedProperties = ''; for (var i in window) { var obj = window[i]; if (obj == null) continue; try { obj._____x = 1; </script> </body> </html>
Update
It was a domain policy that was put in place for a problem with IE6. We found that this policy caused a problem by working with the Microsoft support person who recorded and analyzed how the policies were applied when I reproduced the problem on my work machine.
Another idea you could try is to set up a child organization block in Active Directory so that you have full permissions to modify. Whether to inherit all policies from the corporate one, and then use the binary exception to block the policies until you find the one that causes the problem.