the javascript engine doesn't handle frame url changes (like in "parent.frames.whatever.location.href = ...") correctly if the frameset is in another domain than the frame. the frame url will not be changed, instead the javascript console will report: "Error: uncaught exception: Permission denied to access property" this is a major bug, since it affects the core functionality of thousands of websites, like minordomo.org. to reproduce, go to http://bugs.minordomo.org/index.php and try to select "funding". detailed description: the outer frameset url is http://bugs.minordomo.org/index.php. this calls the top frame (http://minordomo.org/menu.php) and a second frameset (http://minordomo.org/index_development.php) which is then calling further framesets within the minordomo.org domain. what the top frame's buttons try to do is to change the second frameset's url to http://minordomo.org/index_funding.php via javascript (method see above), but it fails because though the frame itself and the target frame are in the minordomo.org domain, the outer frameset is in the bugs.minordomo.org domain (selecting anything in the inner menus works fine, since all these framesets, frames and target frames are in the same minordomo.org domain). to verify that the different domains are the problem here, access the very same outer frameset by its url in the minordomo.org directory tree: http://minordomo.org/bugs/index.php - you'll see that selecting "funding" works fine now. in other words: "parent.frames.whatever.url = " is broken when parent is in another domain than the calling script. i can't figure out any reason why this should result in a permission conflict. there is no need to check my code: this is *not* a programming error on my side, all absolute and relative references in the javascript parts are correct. the site works fine with msie 5.5. in mozilla, this ìs broken in 0.9.3, was broken at least from 0.9 on, and probably before. if you need a simple demo frameset, please tell.

Your code is not working because of a security feature. See bug 45099 for arguments for why this is necessary and bug 52920 and its duplicates for a clear description of the feature...

*** This bug has been marked as a duplicate of 52920 ***

Reopening...

...and marking Wontfix. Two sites in the same domain *can* access each other. Both pages must contain a script that sets the document.domain property to their common suffix. In your case, <SCRIPT> document.domain = "minordomo.org"; </SCRIPT> (the following is copied from 52920) > mozilla's current behaviour makes it impossible for > clubs.domain.org to access secure.domain.org. there > are numerous reasons why clubs.domain.org may need > to do so, and there are no easy workarounds for > websites that rely on frames and subdomains. > please be aware that msie 5.x and opera 5.x support > cross (sub)domain frame access. most users will not > percieve mozilla's behaviour as a fix for a security > flaw in any other major browser, but as a javascript > bug -- so they'll rather return to msie. The easy workaround is described above. This has been Netscape's policy since version 4 and before. How do IE and Opera define a subdomain? Is .com an acceptable common subdomain? What about .co.uk?

PS. I've reopened 52920 for reconsideration. If we decide to fix that, the site mentioned in this bug will work anyway.

Marking Verified WonFix as per above developer comments.

closing this bug is fine, but i don't get the WONTFIX. if this bug is a duplicate of bug 52920 (which is still considered WILLFIX, and i've argued in 52920 why it should be), then bug 93892 should be closed as DUPLICATE, not as WONTFIX. (this is just to make sure that 52920 isn't closed because of this duplicate gone WONTFIX...)