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>
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.
Created attachment 2106 [details] Testcase
Created attachment 2107 [details] Screen shot after link fails to load page in frame 1
Created attachment 4384 [details] Non-working test case file Non-working test case file - attaching separately to demonstrate XSS issue.
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.
Un-assigning, since Maciej isn't actively working on this bug.
Do we still have this bug? Downloading all these reductions is complicated.
This looks to have been fixed for a long time.