Move scrolling state history save/restore from nsScrollBoxFrame to nsHTML/XULScrollFrame

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: roc, Assigned: roc)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Attachment #157804 - Flags: superreview?(dbaron)
Attachment #157804 - Flags: review?(dbaron)
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)
Attachment #157804 - Flags: superreview?(dbaron)
Attachment #157804 - Flags: superreview+
Attachment #157804 - Flags: review?(dbaron)
Attachment #157804 - Flags: review+
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.