How to get around “Access is Denied” in a Window.Open() JavaScript call

I’ve made two changes to the Forms and Field lister I posted yesterday – the original post has been altered to include them.

First and foremost, the line to paste into Start->Run to install the program into the registry was being altered by WordPress. Though the text looked identical, the double quotes were being changed to a different character. The result was you would receive an “invalid key name” error. If, in DOS, you went back and replaced the double quote imposters with actual double quotes, it would run fine. So I have wrapped that line with PRE and TT tags in the original post and provided a batch file in case anyone still has problems.

Second, it was discovered that some Windows computers would block the popup. There would be no error given or any indication of what happened beyond a dialog box flashing up on the screen and disappearing. I debugged this by adding alert(1),alert(2)…alert(n) messages after every line of the source code. Once I did that, IE was kind enough to tell me that it was bombing out due to an “Access is Denied” error triggered from my Window.Open(“”,”tcc_formlist”,””); command. That line worked at my office, but bombed out on one of my home computer.

The reason is that Windows now blocks one window or frame accessing another window or frame that is in a different domain (or security zone I believe). This technique is calls Cross Frame Scripting. The problem is that what I am doing with these tools IS exactly working across two frames/windows. Luckily there is a way around this.

The JavaScript Mini-FAQ, available here: http://www.dannyg.com/ref/jsminifaq.html#q15, has a good description of this issue and the work around:

Q. What does the IE “Access is Denied” error mean?
A. The “Access Denied” error in any browser usually means that a script in one window or frame is trying to access another window or frame whose document’s domain is different from the document containing the script. What can seem odd about this is that you get this error in IE for Windows frequently when a script in one window generates a new window (with window.open()), and content for that other window is dynamically created from the same script doing the opening. The focus() method also triggers the error.
The error can also occur if scripts try to access objects, properties, or methods that have been locked down by Microsoft’s security platoon. For instance, the document.styleSheets.rules property used to be accessible in IE 5 and IE 5.5, but is not in IE 6.

For the new window problem, there is a bit of history associated with the problem and workarounds. For example, the problem occurs frequently when the scripts are being run from the local hard disk. You get a clue about the situation in the titlebar of the new window: It forces an about:blank URL to the new window, which is a protocol:domain that differs from wherever your main window’s script comes from. If, however, you put the same main window document on a server, and access it via http:, the problem goes away.

There is a workaround for the local-only problem: In the first parameter of the window.open() method call, load a real document (even if it is a content-free HTML document) into the sub-window before using document.write() to generate content for the subwindow. The loading action ‘legitimizes’ the window as coming from the same domain as your main window’s document.

(This solution does not affect scripts that load a page from a secure server into a separate window or frame. An http: protocol in one window and https: in the other–even if from the same server.domain–yield a security mismatch and “Access Denied.” Setting the document.domain properties of both pages may solve the problem (but I am unable to test it for sure).)
[…]

I’ve updated the original code to include this fix.
Window.Open(“”,”tcc_formlist”,””);
is now
Window.Open(“file:///c:/Windows/web/formlist.htm”,”tcc_formlist”,””);

The end result is that window.open command quickly opens the script before the dynamic content is displayed. This little blip is not noticeable on my daughters computer. I don’t think it will be a major slowdown. Due to how the code is written, the whole of the JS routine is not executed. The biggest negative is that the script now has a reference to what I expect the file name to be on your computer. If you rename the script, you need to change that reference in the source. I doubt many people will rename the script.

That was kind-of a ramble… Does that all make sense?