User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 In finished web-site http://www.cemh.eclipse.co.uk/JavaJive/FrameJavaJive.html scripts in footer work ok, but when I'm trying to develop on my own drive D:, they fail. Worked in FF 2.x Reproducible: Always Steps to Reproduce: For example, inserting the following to replace the onload="" attribute of the body tag of the footer, onload="javascript:<code>" where code is: var par = window.parent; alert(par); // Alert shows '[object Window]' var par = window.parent.frames; alert(par); // Alert shows '[object Window]' var par = window.parent.name; alert(par); // Script dies var par = window.parent.location; alert(par); // Script dies var par = parent; alert(par); // Alert shows '[object Window]' var par = parent.document; alert(par); // Script dies var par = parent.document.getElementById("body"); alert(par); // Script dies Actual Results: As above Expected Results: Scripts worked in FF2.x

Not sure what exactly to do to test the regression. Can you attach a testcase with instructions?

Also, when you open the console (Tools -> Error Console) there is a chance that you see errors which can explain the problem.

The following lines all give ... Permission denied to get

(In reply to comment #3) Sorry, sent the post accidentally because of a typo ... The following lines all give ... Permission denied to get property Window.document CEMHFrameFooter.html (the javascript in this file is now different to the live version, but that of the others below is unchanged) 30: var par = window.parent.document.URL; CEMHFrameHeader.html 32: var href = window.parent.document.URL.replace(...); CEMHFrameIndex.html 30: branchState( ... , window.parent.document.URL, ... ); Don't recall this occurring on v2.x, doesn't occur on live site, doesn't occur with IEv6.

First, I think I might be mistaken about the FF 2.x assertion, the fault may have been there as well. I have been working mainly on some difficult new pages, which in consequence to their difficulty and the resulting uncertainty to the final layout hadn't yet been added to any of the indexes. In desperation after logging the bug, I added one of them to the frame index last night, and consequerntly I now realise this is just another example of something I've noticed before, possibly as long ago as FF 2.x, though I can't be certain. You asked for a means of reproducing it ... 1) I am supplying a small zip CEMHBug.zip, containing the following files from my site. Unzip it to the local hard drive of any (I suppose) Windows PC: CEMHFrameFooter.html CEMHFrameHeader.html CEMHFrameIndex.html CEMHFrameStyles.css JavaJive/FrameJavaJive.html JavaJive/JavaJive.html 2) In Windows Explorer, navigate to JavaJive folder 3) Double-click (if FF default browser, else right-click and choose 'Open with ... Firefox') JavaJive.html. There are some button images missing, but otherwise page loads without error. 4) Close that FF tab, and then do the same with FrameJavaJive.html. The page loads with the 'Permission denied' errors previously documented (and two other minor ones that can be laid at my door). Clicking the (missing) button 'Version suitable for printing', which normally loads the content frame JavaJive.html outside of the frames, also gives: Permission denied to get property Window.open, line 103 5) Now click 'Java Jive' in the right index frame. The page now loads without the 'Permission denied' errors. The (missing) button 'Version suitable for printing' now works!

Meant to add that the same procedure with files in the root directory of the local site, for example CEMH.html and FrameCEMH.html, doesn't show the problem.

Ok, I see. This problem was caused by Bug 402983 (what I already expected).

Seems like a duplicate of bug 404822. I'm not sure exactly what the final effects of bug 230606 / bug 402983 are, but I think that failing to access files in directories above the loaded file is an expected consequence of the fixes for those bugs.

a) Will this be fixed? b) If so, when? c) If not, how will behaviour on the actual site be affected? Site development is tricky enough as it is, what with at least two different major browsers having their own idiosyncracies to be allowed for, and having fonts on this PC that are not on most web servers, etc. I need another significant difference between the live site and my local version under development like I need a hole in the head. Is this also why scripts which I've started moving into a folder off the root stop working? Thinking they might be more generally useful, I've just moved about five functions from a page several folders down into a file ./Scripts/General.js. Now when I click on any of the page's features that use them, I get 'FunctionName is not defined', even though the page links to the file with a script tag exactly similar to that for another file in the same directory whose functions run ok!

> a) Will this be fixed? In the sense of allowing this script access? No. Doing that would reopen the security hole we were trying to close up. > c) If not, how will behaviour on the actual site be affected? It won't. The security changes only affect file:// URIs. > Site development is tricky enough as it is Fundamentally, any site development using file:// will run into issues with security policies being different for file:// and http://. This is the case in all browsers. I recommend running web server on localhost for your web development. You can also go back to the old (insecure) file:// policy by setting the preference described in bug 404822. Note that doing so _does_ reintroduce a security hole, but it's there precisely for cases like yours. > Is this also why scripts which I've started moving into a folder off the root > stop working? Doesn't sound like it, given your description.