From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010725 BuildID: 2001072503 When JavaScript attempts to access information from a page at another domain, it is blocked with a security warning "Error: uncaught exception: Permission denied to access property" This is expected and a Good Thing. However, minor differences in a URL can cause this to fail and it shouldn't. For example, JavaScript at http://mydomain.com/ is not allowed to access http://mydomain.com:80/ Since 80 is the default http port, it can optionally be included. In both cases, the page is loaded over port 80, so I don't see any reason that JavaScript should restrict access between them--they are the same domain. There is a similar problem with https://mydomain.com/ and https://mydomain.com:443/ 443 is the default HTTPS port. Reproducible: Always Steps to Reproduce: 1. Create a frameset on an SSL site with 2 frames: topframe and bottomframe. 2. For the top frame, use a reference to a page like https://mydomain.com/ without the port. 3. For the bottom frame, use a reference to a page like http://mydomain.com:443/ with the port. 4. Include JavaScript in the bottom frame to try to get the topframe.location.href or otherwise access code in the top frame. (or do the reverse and put the code in the top frame and try to access the bottom frame.) Actual Results: The bottom frame JavaScript will not be able to get the location of the top frame, even though they use the same domain and port (just that it wasn't specified in the URL). Expected Results: The bottom frame's JavaScript should be able to determine the top frame's location. This same problem affects Netscape 4.x. IE 5 does not have this problem. Note that I am only suggesting that this be changed when the domain matches and the port is either the default port or unspecified. I am not suggesting that Mozilla should otherwise loosen the security. I also realize that http://mydomain.com/ and http://mydomain.com:81/ are entirely different and I understand the logic of blocking access between them. It's just with unspecified port and the default port that this needs to change. I wasn't sure whether this should be in the DOM Level 0 or Security component. I think it would work except for security blocking it, so I picked Security.

Added keywords. I'll make a testcase, proposing for Mozilla 1.0, and marking nsenterprise because this blocks a web app that works with IE.

Will do.

See the URL for a testcase with HTTP on port 80 and with an unspecified port. Unfortunately I don't have a convenient server to host a testcase for HTTPS and port 443, but it's basically the same problem. Interestingly, I noticed that IE5 does not display the :80 for frame2 and frame3 in the testcase, even though those frames were loaded explicitly with the port.

I should perhaps mention that when this bug is fixed, frame1, frame2, and frame3 should be able to access the URLs of each other. frame4 at a different domain should not be able to access the others, nor should they be able to access it. In testing you should also verify that pages at the same domain name but using a different port are still denied access.

The current behavior is incorrect, but fixing it would involve a performance hit and would be pretty complicated. So, I'm marking it Future.

A performance hit? Can't port 80 just always be added (or always be removed) before any comparisons are done? Does seem like that'd be a big deal, but I don't know the code enough to even know whereto begin. Also, in bug 95350 and bug 84776 there had to be code written to do the comparisons and handle the port correctly. Perhaps something similar needs to be done here?

Removing nsenterprise nomination.

*** Bug 100859 has been marked as a duplicate of this bug. ***

*** Bug 105793 has been marked as a duplicate of this bug. ***

*** Bug 105694 has been marked as a duplicate of this bug. ***

*** Bug 113839 has been marked as a duplicate of this bug. ***

I just fixed this bug in the guise of bug 125382 - marking dup. *** This bug has been marked as a duplicate of 125382 ***

V/dupe. btw, that bug has no patch, which I find really annoying.