Closed Bug 55359 Opened 24 years ago Closed 24 years ago

Back Button in framesets doesn't properly follow actual browsing history

Categories

(Core :: DOM: Navigation, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED DUPLICATE of bug 46828

People

(Reporter: bcortez, Assigned: radha)

References

()

Details

Mozilla Build ID: 2000100504 The browser Back button does not resurrect the same browing pathway (history) back in time. It has a tendency to go back to the page prior to the loading of the initial frameset as opposed to changing the sub-frame contents. TestCase URL: http://www.ccs.neu.edu/home/bcortez/mozilla_tests/testPage4.html 1. Load the above URL (there will be 3 child frames in the master frameset) 2. Click "Page Number 2" Link in the top left frame 3. The right frame will now contain Page Number 2 4. Click "Page Number 3" Link in the top left frame 5. The right frame will now contain Page Number 3 6. Click the "Back Button" on the Browser Toolbar. 7. Actual Behavior: The page that loads will be the page PRIOR to step 1. Expected Behavior: The child frame should change to the page in step 3 (Page Number 2). 8. Using the "External Site" link in the bottom left frame shows that when you load the inital page into the child frame and select a link in that page, the same behavior is encountered. DEBUG NOTE: The contents of the Back Button drop-down contains only the pages PRIOR to the initial frameset URL. The "History" tool contains absolutely nothing...it's empty. (This in itself doesn't seem correct at all and is probably not working). COMMENT: This is how many sites use framesets and is a major concern. IE5.0 behavior for this testcase is as expected and the child framesets change according to the actual browse history.
I don't see this in today's branch builds. What did you try this on?
As Stated in the original bug report. I was using Mozilla Build ID: 2000100504
I don't see this on the 2000100609 branch bits either. Is it possible this has regressed on the trunk?
Guys, Perhaps I got some flaky interim build or something. Let me grab the latest build Monday morning. I'll install that and re-test it again and post the results here. How does that sound?
that's great bcortez, we'll watch for your results. Your test page is great but if you want a change of pace or independent verification look at: http://www.mozilla.org/quality/browser/front-end/testcases/history/frame-history.html
This sounds a lot like bug 56828
Sorry 'bout the typo... that should be bug 46828...
Grrr... way too many dups of bug 46828.. two more today.. great Asa Dotzler you should really do something about this bug.. either fix it or find a way to avoid all those dups. :-P Too bad I can't change bug status. Fabian.
*** This bug has been marked as a duplicate of 46828 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
VERIFIED Dupe
Status: RESOLVED → VERIFIED
Blocks: 59387
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.