By the way, if you reload either the second or third pages, the correct contents of the IFRAME will be shown.
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/)
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";'
Set target milestone to mozilla0.9
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...
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).
*** 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.
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.
My example works, but the behaviour of Location.replace() with frames is not right (per eyork above and bug 73476, which I've reopened).
When I click on the link "day", a location.replace seems to happen on the parent of the subframe, Is that right?
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. ***
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.
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.]