Location.replace(aHref) and incorrect loading of IFRAME SRC

VERIFIED FIXED in mozilla0.9

Status

()

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

People

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

Tracking

Trunk
mozilla0.9
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Internal URL], URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Overview Description:
  The use of javascript 'Location.replace(aHref)' results in the
  incorrect loading of <IFRAME src=''> at the new URL.

Steps to Reproduce:

1) Load http://jrgm.mcom.com/framebug/firstPage.html

2) This will automagically call
     document.location.replace("http://jrgm.mcom.com/framebug/secondPage.html");
   after 5 seconds.

3) When that page loads, the IFRAME it contains, while it has a SRC value
   of 'http://www.mozilla.org/', will load in the contents of the previously
   visited URL.

4) After 5 seconds, that page will call
     document.location.replace("http://jrgm.mcom.com/framebug/thirdPage.html");
   and again the IFRAME will have the wrong content (should now be Yahoo).

Actual Results:
  Somehow the .replace() call is not having the correct effect on page loading.

Expected Results:
  The three pages should show netscape then mozilla.org, then yahoo.com in the
  IFRAME.

Reproducibility: 100% win2k

Build Date & Platform Bug Found:
  2000112804 win2k
  2000112708 mac (os9.0)
  2000112708 linux (rh6.1)

Additional Information:
  This also applies to <frameset><frame>...
(Reporter)

Comment 1

17 years ago
By the way, if you reload either the second or third pages, the correct contents
of the IFRAME will be shown.

Comment 2

17 years ago
This bug is also effecting iPlanet Calendar Express 5.0. Most of the links on
the page have the problem described here. (The internal website is at
http://ical.red.iplanet.com:8080/)
(Reporter)

Comment 3

17 years ago
Adding nsbeta1 -- this really does need to be fixed. In addition, I suppose
there might be a security hole here. And, I would like to be able to use 
this in some of my testing as an alternative to 'Location.href="someURL";'
Keywords: nsbeta1
Set target milestone to mozilla0.9
Target Milestone: --- → mozilla0.9

Comment 5

17 years ago
Sounds like a problem with SH pre-empting load of a frame with the wrong url.
CC'ing Radha, but continuing to look into this one...
Status: NEW → ASSIGNED

Comment 6

17 years ago
Hi Radha - after looking through this one, what appears to be happening is that
we are reusing the same sh entry over again when location.replace is called.  It
is being treated exactly the same as a reload, so the current url in frames and
iframes is saved and then restored on the new page (this bug).
Assignee: pollmann → radha
Status: ASSIGNED → NEW
Component: HTMLFrames → History: Session
QA Contact: petersen → claudius
Target Milestone: mozilla0.9 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Comment 7

17 years ago
*** Bug 73476 has been marked as a duplicate of this bug. ***
I don't see the problem anymore. After the first page is loaded, in 5 seconds,
mozilla.org loads in the IFRAME  and then yahoo.com loads. Marking WFM. Please
reopen if the problem persists.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 9

17 years ago
This is still a bug. I am using the the nightly build as of 3/28/01. The iPlanet 
Calendar Express 5.0 server is at http://ical.red.iplanet.com:8080/. You can use 
your netscape id to login. It's better then before. This ui has two frames. When 
replace is called on the top window, the lower frame is updated. The top frame 
has the last url of lower frame. If you press return on the url line, the correct 
urls are loaded for each frame. To reproduce this: login, click on the "day" link 
to go to the day view. Notice the upper frame now has the url from lower frame.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 10

17 years ago
My example works, but the behaviour of Location.replace() with frames is 
not right (per eyork above and bug 73476, which I've reopened).

Updated

17 years ago
When I click on the link "day", a location.replace seems to happen on the parent 
of the subframe, Is that right?
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9

Comment 12

17 years ago
Yes that correct, the parent frame is updated.
I see some goofy behavior on the above site (ical.red.iplanet.com) on Nav 4.7

This is what I see...
1) Go to above site and login. 
2) You are shown a 2 frame page. The bottom frame shows the week ahead
3) Click on "day" in the bottom frame. A day view for today is shown
4) Click back. You go to 2). And the forward button is disabled.
5) Click back again, you go to page 3, the day view, instead of going to the 
login page or some other default page in place of the login page, 'coz you have 
already logged in.
5) Any further back operation simply cycles between page 3, the day view and 
page 2 the weekly view.

I see this behavior in Nav 4.7. Is there any document.write() or onload 
handlers?  I'm presuming the top frame has the same url for both the pages. 

Bug 75885 seems to be a dupe and has a testcase.
*** Bug 75885 has been marked as a duplicate of this bug. ***
Created attachment 31186 [details] [diff] [review]
simple test case attached
Created attachment 31212 [details] [diff] [review]
patch to docshell

Comment 18

17 years ago
r=valeski

Comment 19

17 years ago
To answer the "goofy behavior" question:

On IE the back and forward action work. On Nav 4.77, it does have a "goofy 
behavior". When the day link is clicked a javascript function "newViewCommand" 
is called. It will call location.replace with a new url on the frame is the 
parent of these two frames. The urls for each frame are different. One of the 
url attributes is different.

Comment 20

17 years ago
sr=rpotts.

why does reversing the traversal of the SHEntry children fix the problem?

-- rick
When the children were removed in the 0--n order, due to shifting of elements 
inside nsVoidArray, the last few children didn't get removed. The stale SHEntry 
hung around and displayed wrong url in the frame, even though right things 
happened for the following location.replace(). By removing the children in the 
reverse order, all children are removed properly.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
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.