Closed
Bug 61557
Opened 24 years ago
Closed 23 years ago
Location.replace(aHref) and incorrect loading of IFRAME SRC
Categories
(Core :: DOM: Navigation, defect, P3)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: jrgmorrison, Assigned: radha)
References
()
Details
(Whiteboard: [Internal URL])
Attachments
(2 files)
908 bytes,
patch
|
Details | Diff | Splinter Review | |
697 bytes,
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
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/)
Reporter | ||
Comment 3•24 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
Comment 5•24 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•24 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 → ---
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 8•23 years ago
|
||
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
Closed: 23 years ago
Resolution: --- → WORKSFORME
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•23 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).
Whiteboard: [Internal URL]
Assignee | ||
Comment 11•23 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•23 years ago
|
||
Yes that correct, the parent frame is updated.
Assignee | ||
Comment 13•23 years ago
|
||
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•23 years ago
|
||
Bug 75885 seems to be a dupe and has a testcase.
Assignee | ||
Comment 15•23 years ago
|
||
*** Bug 75885 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 16•23 years ago
|
||
Assignee | ||
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
r=valeski
Comment 19•23 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•23 years ago
|
||
sr=rpotts. why does reversing the traversal of the SHEntry children fix the problem? -- rick
Assignee | ||
Comment 21•23 years ago
|
||
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
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 22•22 years ago
|
||
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.
Description
•