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

Status: VERIFIED FIXED

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

Description

[John Morrison]

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>...

Comment 1

[John Morrison]

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

Comment 2

[eyork]

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/)

Comment 3

[John Morrison]

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";'

Comment 4

[Kevin McCluskey (gone)]

Set target milestone to mozilla0.9

Comment 5

[Eric Pollmann]

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...

Comment 6

[Eric Pollmann]

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).

Comment 7

[Keyser Sose]

*** Bug 73476 has been marked as a duplicate of this bug. ***

Comment 8

[Radha on family leave (not reading bugmail)]

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.

Comment 9

[eyork]

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.

Comment 10

[John Morrison]

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

Comment 11

[Radha on family leave (not reading bugmail)]

When I click on the link "day", a location.replace seems to happen on the parent 
of the subframe, Is that right?

Comment 12

[eyork]

Yes that correct, the parent frame is updated.

Comment 13

[Radha on family leave (not reading bugmail)]

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. 

Comment 14

[Andreas M. "Clarence" Schneider]

Bug 75885 seems to be a dupe and has a testcase.

Comment 15

[Radha on family leave (not reading bugmail)]

*** Bug 75885 has been marked as a duplicate of this bug. ***

Comment 16

[Radha on family leave (not reading bugmail)]

Attachment: simple test case attached

Comment 17

[Radha on family leave (not reading bugmail)]

Attachment: patch to docshell

Comment 18

[Judson Valeski]

r=valeski

Comment 19

[eyork]

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

[rpotts (gone)]

sr=rpotts.

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

-- rick

Comment 21

[Radha on family leave (not reading bugmail)]

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.

Comment 22

[sairuh (rarely reading bugmail)]

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.]