Bug 3272 – Page fails to load in frame that uses top.location.replace

• Component: Frames
• Status: RESOLVED FIXED

[Chris Petersen]

Expected Results: The page should load in the current frame or load in the window

What I got:  The page doesn't load in frame.


Steps to reproduce:

1) Download and uncompress the file called "testcases.zip"
2) Open "test_frame.html" This is a frameset that uses two frames.
3) Click on "Link 1" in the top frame. This link references a url called "http://disney.go.com/
disneypictures/incredibles/". However, no content is displayed in the frame . If you look at the page 
source of this frame now, you will see this page did load but the SCRIPT element in the HEAD didn't get 
processed.

<script language="JavaScript" type="text/javascript">
top.location.replace('http://disney.go.com/disneyvideos/animatedfilms/incredibles');
</script>

[Chris Petersen]

This test case fails in Safari 2.0 (v412) under 10.4.1 (8B15). However, the test case does function in 
Firefox 1.0.4. With Firefox, the linked URL loads directly into the entire browser window and not in the 
actual frame.

[Chris Petersen]

Created attachment 2106 [details]
Testcase

[Chris Petersen]

Created attachment 2107 [details]
Screen shot after link fails to load page in frame 1

[Daniel Udey]

Created attachment 4384 [details]
Non-working test case file

Non-working test case file - attaching separately to demonstrate XSS issue.

[Daniel Udey]

Created attachment 4385 [details]
Main test case files for Frames-XSS issue

Here is the completed test case for this bug (depends on attachment 4384 [details] to
function).

The problem in this bug is that Safari is preventing the Javascript from
working due to XSS prevention. When the parent HTML file (the frameset) is on a
different domain than the frame, the frame is not allowed to modify any of the
parent's parameters. This includes using top.location.replace() to change the
URL, and because of this XSS prevention, the link in question does not work,
and sites using this Javascript are not able to 'break out' of the frames.

Usage: Download the zip file and extract locally, then launch
frames-xss-testcase.html from the archive. The bottom frame will load the local
page, and the top frame will load attachment 4384 [details] from the Bugzilla page. Click
the link in the top frame and you will see an XSS warning and a Javascript
error (related to the warning) appear in your Javascript console (or your
console.log). Click the link in the bottom frame, which uses the same
Javascript, and it will work. The reason is that the bottom frame and the
frameset are in the 'filesystem' domain, while the top frame is in the
'bugzilla.opendarwin.org' domain, and is thus not allowed to modify the
frameset URL.

The best fix is most likely to allow frames to access the
top.location.replace() method and top.location.href property despite XSS
concerns, because redirecting the user to a new site in a fresh frameset is
most likely not an issue.

[Alexey Proskuryakov]

Un-assigning, since Maciej isn't actively working on this bug.

[Adam Barth]

Do we still have this bug?  Downloading all these reductions is complicated.

[Adam Barth]

This looks to have been fixed for a long time.