User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9) Gecko/2008052906 Firefox/3.0 Given a frameset, which references a subframe that is located in the parent directory. The subframe file accesses parent.location by javascript. It the frameset file is openen locally ("file:///") an error is thrown: "Permission denied to get property Location.href" Reproducible: Always Steps to Reproduce: 1. Unzip attached testcase e.g. to C:\testcase 2. Open frameset.htm locally (e.g. file:///C:/testcase/dir/frameset.htm) 3. Open Error Console Actual Results: "Permission denied to get property Location.href" is shown in Error Console See also bug 440572

Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1206193800&maxdate=1206205379 -> 402983.

This is by design, as things stand...

The bug only manifests if the files are loaded from the local filesystem. To replicate, open the browser on the MainDir/index.html file. For convenience, an index.html file in the top directory will redirect to the one that demos the bug.

This bug appears to be a manifestation of a more general problem concerning retrieving a property from a frame-parent if the source-file needs to be accessed by climbing upwards through the directory-tree. The more elaborate testcase I attached shows that this bug and the phenomenon I originally reported as an extension to Bug 422120 both follow the same pattern. It also clearly demonstrates the conditions that do and don't exercise the bug.

Some additional observations: (1) When the file is loaded via a redirect from the index.html file in the top directory (the one I included "for convenience"), the bug does not appear. But if the MainDir/index.html file is loaded directly -- even in a neighboring tab in the same browser-window -- the bug does appear. (2) The Error Console message refers to "Window.<nameOfVariable>" but the source of the subordinate IFRAME module refers to the variable as "parent.<etc...>" I don't know what, if any, significance the transformation from "parent" to "Window" has, but this might be worth investigating...

(In reply to comment #2) > Regression range is ... bug 402983. bug 230606 actually. As Boris said, this is by design. It's unfortunate that there are legitimate cases that this interferes with, but there's no way to distinguish those from attack scenarios. Load the files through a local web server and you won't hit these problems. Or if you start your app from the topmost directory then you should be able to access files beneath it, but you can't reach "up". If this is for your own personal use then you can change the value of security.fileuri.strict_origin_policy and revert to the older vulnerable behavior. Just becareful what other things you download and then load from your local filesystem.

Okay, thanks for the clarification and the pointer to the more detailed discussion. Indeed, I hit this problem while developing and locally testing my site, which uses frames that communicate via scripts. Now that I understand, then as long as the scripts work in the actual web-site and I know how to work around this "problem" while testing, I'm happy.