Closed Bug 73476 Opened 23 years ago Closed 23 years ago

location.replace() causes history list to malfunction

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: aogun, Assigned: radha)

Details

Attachments

(1 file)

Patch to docshell
1.21 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
BuildID:    2001021508

When a location.replace() command is carried out in a frame, the history list 
for the page will no longer work correctly, i.e. if the user then navigates 
from that frame to a new one, he will not be able to return via the back button 
or the history list.


Reproducible: Always
Steps to Reproduce:
1. Place the 5 files below in the same directory on a webserver.

2. View the file "ns6frameset.html".  The frame that says "Move on to next 
page" has had its location replace()d as soon as the frame was loaded.
   Now the history list of the page no longer works correctly, as shown below.

3. Follow the link "Move on to next page".  This link does not do a replace(), 
so it should be possible to go back to this page.

4. Now try to use the back button.

---------------------------------- File 1: ns6frameset.html --------------------
-----------
<html>
<head>
</head>
<frameset name="mainframeset" cols="50%,50%">
	<frame name="nothingframe" src="detail.html" scrolling="auto">
	<frameset name="rightframeset" id="rightframeset" rows="77%,*">';
		<frame name="higher" src="ns6test.html" target="DCS" 
scrolling="auto">
		<frame name="DCS" src="detail.html" scrolling="auto">
	</frameset>
</frameset>
</html>

---------------------------------- File 2: detail.html -------------------------
-----------
<html>
</html>

---------------------------------- File 3: ns6test.html ------------------------
------------
<html>
<head>
<script>

function onLoad()
{
	parent.frames.higher.location.replace("ns6cgi.html");
}
</script>
</head>
<body onload="onLoad()">
</body>
</html>

---------------------------------- File 4: ns6cgi.html -------------------------
-----------
<HTML>

<BODY>

<A HREF="newdoc.html">Move on to next page</A>

</BODY>
</HTML>


---------------------------------- File 5: newdoc.html -------------------------
-----------
<HTML>
<BODY>
<P>Now try to go back if you can
</BODY>
</HTML>





Actual Results:  The browser does not change its location.

Expected Results:  The browser should return to the page "Move on to the next 
page".
i think this is a dupe.
Assignee: asa → radha
Component: Browser-General → History: Session
Keywords: qawanted
QA Contact: doronr → claudius
Whiteboard: DUPEME

*** This bug has been marked as a duplicate of 61557 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
vrfy dupe
Status: RESOLVED → VERIFIED
The other example is suddenly WFM with no known reason. But this case, or
its analog in http://jrgm.mcom.com/framebug/thirdPage.html is still open.

In my example, when the second Location.replace has occurred, hitting the
back button will take you back (it shouldn't of course). This doesn't occur
if you use Location.replace with simple documents (e.g., no (i)frames).

The pages for my test case are like so:
<html><head><script>
function nextPage() {
  var href  = "http://jrgm.mcom.com/framebug/thirdPage.html";
  document.location.replace(href);
}
</script></head><BODY onload="window.setTimeout(nextPage,5000);">
 
<p>This page will do <br>
<code>document.location.replace("http://jrgm.mcom.com/framebug/thirdPage.html")
;</code>
<br>in 5 seconds.
</p>
<iframe width=500 height=300 id="frame-two" src="http://www.mozilla.org/">
</body></html>
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla0.9
r=valeski. you might want to remove the "Fixes bug 73476" part in the comment
though. if someone wants to know what the code was changed for, they can see
that in the cvs comment (bug numbers are required for checkins) in a cvs log of
the file.
looks good to me.  (sr=rpotts)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Fix checked in.
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: