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)
Tracking
()
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.
Assignee | ||
Comment 1•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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?
Comment 5•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
*** This bug has been marked as a duplicate of 46828 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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
•