This is a step towards the goal of eliminating nsScrollBoxFrame. I will attach a patch that moves the session history save/restore code from nsScrollBoxFrame to nsHTML/XULScrollFrame. Apart from the main goal it has some nice side effects: -- nsPresShell no longer needs to know about the scrollframe guts -- nsListControlFrame had some fairly bogus save/restore code of its own that can now be eliminated The only tricky thing about this patch is making listbox save/restore continue to work. To be honest I'm not sure how it was working before --- in fact, it really wasn't. The listbox and its scrollbox *both* tried to restore history and also competed with nsListBoxFrame::ResetList trying to scroll to the selected option. On trunk, usually ResetList wins which means any selected item will be scrolled into view when you return to a page. I regard this as a bug because it means listbox scroll history is currently mostly useless. It's a tricky problem because we want user interaction which causes list changes to scroll the list to the selected option even if the page is still loading. What I have done is suppressed scrolling the selected option into view if it's triggered by a change before the SELECT element is done loading and we have scroll history to restore.
14 years ago
Comment on attachment 157804 [details] [diff] [review] fix as described The listbox thing sounds a bit like some of the anchor scrolling problems in bug 110329. r+sr=dbaron (without really looking at the patch)
Yeah, it is similar to the anchor scrolling problems --- the problem is how to decide who wins when we have multiple agents who would each like to determine the final scroll position. Checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Maybe this has caused bug 260624?
You need to log in before you can comment on or make changes to this bug.