location.replace() causes history list to malfunction

VERIFIED FIXED in mozilla0.9

Status

()

Core
Document Navigation
P3
major
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: aogun, Assigned: Radha on family leave (not reading bugmail))

Tracking

Trunk
mozilla0.9
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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".

Comment 1

17 years ago
i think this is a dupe.
Assignee: asa → radha
Component: Browser-General → History: Session
Keywords: qawanted
QA Contact: doronr → claudius
Whiteboard: DUPEME

Comment 2

17 years ago

*** This bug has been marked as a duplicate of 61557 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
Whiteboard: DUPEME

Comment 3

17 years ago
vrfy dupe
Status: RESOLVED → VERIFIED

Comment 4

17 years ago
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

Comment 6

17 years ago
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.

Comment 7

17 years ago
looks good to me.  (sr=rpotts)
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 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

Updated

10 years ago
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.