I went to www.cinescope.com and all hell broke loose. These two sites are very similar in structure - yet one works and the other doesn't. I just followed the steps outlined above.(here they are again) 1. Surf to http://www.dmoz.org 2. Type http://www.cinescope.com 3. Click Left-hand frame - 'Forums' 4. Click RHS 'Guest Access' 5. Click any from the list of forums. 6. Click 'Back' I went at least two pages back(instead of the one). You don't even have to do Step 5. I clicked back after Step 4 and went back to dmoz.org
sorry to do this at so late a juncture but mozilla.org's formating broke my html and it took me this long to get the min testcase working right. I tried to tell PDT before, anyway... At the url above is the 'standard' min testcase for this specific feature. It fails horribly. frankly, i don't know why it works on _any_ sites if this doesn't work. The test case contains steps to repro. Does not work on all platforms with the 2000080204/5 m17 branch builds.
I recreated this problem on all m17 builds today. Seems like session history for frames is broken. This works just fine if I visit a few pages and just go BACK and FORWARD and pages load in the proper order.
Not sure where we left off with this one after PDT today. It is ugly, but thought I heard pass for hold..jar? do you remember?
I think the call for beta2 at this point is that the risk is too great to try to repair frame history (on short notice, and with little/no cook time possible). I believe I'm playing back the concensus of the discussion on Friday... so I'm going to go ahead and beta2-minus this bug.
Whiteboard: [nsbeta2+] NEED PDT FINAL DECISION → [nsbeta2-]
Putting on relnote2 radar.
nav triage team: too important to minus
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
cc'ing mscott & rick, The problem here is, docshell does not have proper loadtype. In the mozilla.org test case url, provided above, a) Follow the steps to reproduce. b) After step # 2, the loadtype in the subframe "main"(the bottom one) is loadHistory (due to the back/forward action) c) When you click on the link "Third" in step #3, nsDocShell::InternalLoad() is called in the top frame with loadtype "loadLink" which passes the control to the uriloader for target "main". d) uriLoader then calls the nsDocShell::OnLoadingSite() on the target frame("main"). But it does not pass any loadtype to it. So, in nsDocShell::OnNewUri() for the targer subframe, we continue to use the loadtype set by previous loads which in this case happens to loadHistory. When loadType is loadHistory, it does not get added to SH. therefore the misbehavior. UriLoader should pass a loadtype in its callback, OnLoadingSite().
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta3+] Need input from mscott
PR2 is out...adding [nsbeta2-] Already has [nsbeta3+]
Whiteboard: [nsbeta3+] Need input from mscott → [nsbeta3+][nsbeta2-] Need input from mscott
Whiteboard: [nsbeta3+][nsbeta2-] Need input from mscott → [nsbeta3+][nsbeta2-] mscott to provide input after return from vacation
*** Bug 50029 has been marked as a duplicate of this bug. ***
Radha, do you mind if I take this from you? If the only problem is what you mentioned above with the load type not being propogated properly than I have a fix for that. Unfortunately, www.cinescope.com is in korean! So I can't perform Claudius's tests on that page to verify if I really do have it fixed. However, general testing on warp.mcom.com (which uses frames) with my changes seemed to see session history working much better!! There was one caveat. I am able to get into a case where I assert in nsDocShell::GetChildAt because index wasn't in a valid range. So you get stuck on a certain page. This happens most often when: 1) browsing through some frame pages on warp. Click on a link from the TOC frame that leaves warp (so you lose the TOC frame). i.e. click on User Experience which loads gooey.mcom.com. The document loads correctly, the frames are torn down. Then hit the back button...Oops, we get this assertion and we fail to go back to the warp.mcom.com pages. That was the only problem I could get myself into when mixing session history with frames on warp.mcom.com after the patch I'm about to attach.
Assignee: radha → mscott
Status: ASSIGNED → NEW
scott, the changes look OK to me. i will look in to the assertion once we we have this in place.
this is now fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
*** Bug 48776 has been marked as a duplicate of this bug. ***
VERIFIED Fixed with 2000091312 builds (using testcase in url field of this bug)
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.