Open
Bug 292955
Opened 20 years ago
Updated 2 years ago
fastback/bfcache doesn't work well with framesets
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
NEW
mozilla1.9alpha1
People
(Reporter: bzbarsky, Unassigned)
References
()
Details
At the moment, if you perform a subframe traversal and then leave the frameset page, bfcache will be disabled on back. Testcase in the URL field.
| Reporter | ||
Updated•20 years ago
|
Blocks: blazinglyfastback
Comment 2•19 years ago
|
||
WFM: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050721 Firefox/1.0+
Comment 3•19 years ago
|
||
Well caching wise (you can also see bug 301397 happen with the frameset), this seems to work fine with: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+ but with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+ it eats up 100% cpu usage and doesn't recover (doesn't die, but window stops redrawing) after pressing back on the last page. Perhaps this should be filed as a separate bug?
| Reporter | ||
Comment 4•19 years ago
|
||
Yes, please file one bug per problem. This bug is about a specific issue; any other misbehavior should get a separate bug.
Comment 5•19 years ago
|
||
Sorry, please ignore this report from comment #3 (and it does recover, it just takes 15 minutes or so), I tried it with a new profile and it works fine. It looks like the HTML Validator extension is choking on the page.
Comment 6•18 years ago
|
||
Unassigning subframe-traversal bugs, this behavior is currently pref'd off (browser.sessionhistory.cache_subframes defaults to false).
Assignee: bryner → nobody
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•