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.

Comment on attachment 56123 [details] [diff] [review] Updated patch r=adamlock

Comment on attachment 56123 [details] [diff] [review] Updated patch sr=rpotts@netscape.com

fix checked in.

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.

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.

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.