Closed Bug 56053 Opened 24 years ago Closed 24 years ago

can't set location.href across domains (setting location works)

Categories

(Core :: Security: CAPS, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: spam, Assigned: security-bugs)

References

()

Details

2000100918 linux go to http://www.sol.no/nyheter/ In the left menubar there is a couple of grey boxes, the top one reads "Aviskiosken". Click the image-link there (same wording) A small tall window appears, with some top tabs and selectbox for various national and international newsmedia. Click one of the items in box - it works, the page loads in main window. Now click one of the tabs. A new box with various other selections appear. Click one of those, and from now on every selection you perform only return an error, also if you go back to the initial tab. The links that formerly worked work no more. JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "http://www.sol.no/nyheter/cgi-bin/avisoversikt.cgi Line: 11"] NC 4.75 has no problems with it. Trying DOM level 0 for starters.
Ok, so here's what's happening here. Clicking on the "Aviskiosken" link brings up a small window from www.sol.no. Clicking on one of the items in the list in the small window will replace the main window with a different URL, for example, 'http://www.adresseavisen.no/'. Now, the next time one of the items in the list in the small window is clicked the small window executes this code: opener.location.href="..."; and that code fails since the window where this happens is from 'www.sol.no' and the 'opener' is now from 'www.adresseavisen.no'. Mitchell, is this intentional? It seems like mozilla would need to allow that anyone can *set* location.href in all cases without checking for same-origin for this site to function, sounds scary scary to me.
Assignee: jst → mstoltz
More principal problems...looking at it...
Status: NEW → ASSIGNED
Here another, similar case: -From a new window with no URL loaded: Go to http://www.nostatic.org/grip/ -Scroll down the upper frame till the "Download" section, and click link "here" This loads the sourceforge page for the app in upper frame. The bottom frame is still the one from the grip page. Notice that the back-button is disabled. (This is probably the good old "back doesn't work with frames" bug. -Now: click image link "Groove" in bottom menu frame. The link is: javascript:OpenTop('http://www.nostatic.org/grip/grip.html') -Clicking it after the sourceforge frame is loaded spawns only the error, and nothing loads: (Clicking the link while still at the original "grip" url loads the frame OK.) JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "http://www.nostatic.org/misc/sound.html Line: 8"] NC 4.75 has no problems with this. Both "Back" and the links all work OK.
Mozilla doesn't let you set location.href for a window that is currently at another domain, but it does let you set location. IE and NS4 allow setting either location or location.href. I'm testing this by typing/pasting javascript:void(window.open("http://www.mozilla.org/")); into a browser window at a webpage and then pasting javascript:void(opener.location.href="http://www.slashdot.org/"); into the window that pops up. (I filed bug 59570 for a recent regression in the console error printed after pasting the second url.)
Component: DOM Level 0 → Security: CAPS
OS: Linux → All
Hardware: PC → All
Summary: links stop working → can't set location.href across domains (setting location works)
*** Bug 60979 has been marked as a duplicate of this bug. ***
*** Bug 57409 has been marked as a duplicate of this bug. ***
*** Bug 68782 has been marked as a duplicate of this bug. ***
*** Bug 56967 has been marked as a duplicate of this bug. ***
Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the XPConnected DOM and its associated security UI changes.
Target Milestone: --- → mozilla0.9.1
QA Contact: desale → ckritzer
QA Contact -> ckritzer@netscape.com
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Yes, fixed. Tested on a current CVS build, Linux: Now it works :)
Hmmm... This seems to be working fine on 2001-05-22-xx builds for Linux & Windows, but not on the 2001-05-21-21 build for Mac (don't have Mac bits for 22nd yet). I'll check again after I get the Mac bits for the 22nd.
Okay, works on the 2001-05-22-09-trunk MOZILLA Mac bits Marking VERIFIED FIXED on: -MacOS91 2001-05-22-09-trunk MOZILLA -Win98SE 2001-05-22-06-trunk -LinRH62 2001-05-22-05-trunk
Status: RESOLVED → VERIFIED
Depends on: 82159
You need to log in before you can comment on or make changes to this bug.