This bug has been taken from bug 99638, I suffer from this problem CONSISTENTLY on my personal web site. I log in to my site and maintain a session ID in the query string. My site uses frames and TARGET="_top_" to manipulate the window. If I click on such a link that takes over the window and click back, I lose my login query string. Additionally, If I clicked that link from a non-default page in a frame (ie. not the page specified in the frameset), it does not return to that page either, but only the default page. Additionally when I log in, I cannot click back through pages in a frame... Perhaps I should create a login on my site for you to tinker with: http://kuipers.dhs.org:1333/ Click the Links link. Click Back. It works. Click on the Family link and enter the following login info: moztest M0ZqaT35T Now click one of the Links icon on the left. Try clicking back. For me it doesn't work. Notice the query string. On the Links page, pick Slashdot. Click Back. Notice the query string is gone and the Links page is also gone (it's back to the default page). This is on Mandrake Linux 8.0, Mozilla 0.9.5 (build 2001101202). I have always had touch and go luck with navigating frames on my site using back. 0.9.5 introduced the elimination of the querystring.
This is what's going on here. After you fill in the login and password, the family page is loaded in the right frame, but before it could be displayed, the _top is replaced by a new page with session-id etc.... , which looks identical to the previous page. This replacement of the _top, after a series of subframe navigations was confusing session history. The patch attached makes sure that replacement loads in the _top as well as in subframes are clearly identified in session history which will enable smooth behavior of the back and forward button.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Summary: Session history misbehaves from subframes replace page on the _top → Session history misbehaves when _top is replaced after a series of subframe navigations
Attachment #56113 - Attachment is obsolete: true
Comment on attachment 56123 [details] [diff] [review] Updated patch r=adamlock
Attachment #56123 - Flags: review+
Comment on attachment 56123 [details] [diff] [review] Updated patch firstname.lastname@example.org
Attachment #56123 - Flags: superreview+
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Nominating for the 0.9.4 branch.
This fix is needed for successful fix of Bugzilla bug 11600 (see comment #45 there). radha would you expect any additional dependencies if this patch goes to the branch now?
Please use this link for the bugscape bug: http://bugscape.netscape.com/show_bug.cgi?id=11600
can we get a 0.9.4 patch w/ this?
per discussion w/ av and radha. this bug is no longer blocking the bugscape bug.
Keywords: edt0.9.4 → edt0.9.4-
Re-nominating for 0.9.4 branch. we need this patch in the 9.4 branch to take care of some serious siebel problems(see bug 128379) I have a tree with this patch ready to go. This has baked in the trunk for almost 3 months. I would like to check this into 0.9.4 branch today. Sun has also verified that this patch fixes their problem.
Keywords: edt0.9.4- → edt0.9.4
Created attachment 73295 [details] [diff] [review] Patch to 0.9.4 branch This patch is suitable for the 0.9.4 branch. It has fixes for this bug and to bug 103850. The changes related to this bug are in the following files nsISHistoryInternal.idl nsSHistory.cpp nsDocShell.cpp (2nd and 3rd segments) The changes related to bug 103850 are in nsDocShell.cpp (first segment)
I checked Radha's patch into the AOLTW branch.
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.