Closed
Bug 73203
Opened 23 years ago
Closed 23 years ago
Broken link behavior in HTML framesets
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
People
(Reporter: dr, Assigned: jst)
References
Details
(Keywords: dom0)
Here are four small HTML files comprising a frameset: frameset.html: <html> <head> <title>mozilla javascript target frame bug</title> </head> <frameset cols="50%, 50%"> <frame src="left-initial-frame.html" name="left"> <frame src="right-initial-frame.html" name="right"> </frameset> </html> left-initial-frame.html <html> <body> <p><a target="right" href="link-target.html" onClick="window.location='link-target.html'" >click to replace both frames</a></p> </body> </html> right-initial-frame.html <html> <body> <p>(right initial frame)</p> </body> </html> link-target.html <html> <body> <p>if you can see this in both frames, the test passed.</p> </body> </html> The expected behavior, when you load "frameset.html" and click on the link, is that both frames load "link-target.html" (the left frame, because of the javascript, and the right frame, because of the href). In Mozilla (2001-03-22) the right frame correctly displays the target page, but the left frame shows up blank. To get the left frame to display correctly, you must drag the frame divider to trigger a reflow. Note that this is the simplest testcase I could find. I tried two simpler testcases: one where there were no frames at all, and the only link was a <span onClick="window.location='...'">; and one where there were frames but only the left frame was supposed to update (again, using the span). Both of those cases worked, so I think this is the simplest one. It's a slightly pathological testcase, but it shows up more often than you would think. Some pages commonly are structured in this way, where the left frame contains a tree view or index of a repository of pages and the right frame contains the current page of interest. Both pages need to be updated when a link in the left frame is clicked.
Oracle uses web-based task management software which exhibits this behavior in Mozilla/Netscape 6. This blocks them from adopting NS6. Nominating for 0.9.
Keywords: mozilla0.9
Keyword spammage (sorry about this). Most importantly, nominating nsbeta1 and marking catfood (indicating oracle employees' dissatisfaction).
Severity: minor → normal
Updated•23 years ago
|
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 3•23 years ago
|
||
The patch attached to bug #65777 should fix this problem.
You need to log in
before you can comment on or make changes to this bug.
Description
•