Closed Bug 301439 Opened 15 years ago Closed 15 years ago

Listbox isn't scrolled to the right position when going back in history

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: roc)

References

()

Details

(Keywords: regression, testcase)

Attachments

(4 files)

To reproduce:

- Go to url
- Scoll listbox of 'Product', select 'Core'
- Scroll listbox of 'Component', select 'Layout'
- In the search input box, type: 'scroll position'
- Begin the search.
- After the search page has loaded, go back.

Result:
'Product' listbox is not scrolled to the position before the search.

This used to work at least in Mozilla1.7.
Attached file testcase
Removing the align="left" from the table cell in this testcase seems to fix the
bug.
Keywords: testcase
I forgot to say, this can only be seen with bfcache turned off.
I'm guessing 64510 based on the align="left".
Did it happen with align="right" before that checkin?
Attached file related testcase
This testcase shows the underlying problem: if you scroll down the list and
then resize the window, we jump back up to the top.

The problem is that listboxes do two-pass reflow. In the first pass, the
computed height is explicitly set to unconstrained. This means the scrollframe
expands to its intrinsic height, notices that the vertical scrollbar is no
longer needed, and sets the scrollbar's maxheight to zero, which forces the
current position to also be zero.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attached patch fixSplinter Review
This fixes the bug by telling the scrollframe that we will do a second pass and
it should not adjust scrollbar layout yet.

I'm a bit worried that something similar could happen to overflow:auto blocks
in tables, where a speculative unconstrained-width reflow could cause the block
to fit all in one line, scrolling it to the top. But I can't make that happen
in a testcase.

I'm surprised this bug hasn't been noticed before!
Attachment #190067 - Flags: superreview?(dbaron)
Attachment #190067 - Flags: review?(dbaron)
Flags: blocking1.8b4? → blocking1.8b4+
Attachment #190067 - Flags: superreview?(dbaron)
Attachment #190067 - Flags: superreview+
Attachment #190067 - Flags: review?(dbaron)
Attachment #190067 - Flags: review+
Comment on attachment 190067 [details] [diff] [review]
fix

need approval for this history bug (blocker)
Attachment #190067 - Flags: approval1.8b4?
Attachment #190067 - Flags: approval1.8b4? → approval1.8b4+
checked in
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Surprisingly, it looks like this reduced Tp on btek a bit.
That suggests it might be worth trying to suppress scrollbar reflow in combobox
dropdowns until the dropdown is shown.

Actually post-reflow-refactor, we might be able to entirely suppress reflow of
the combobox dropdown until it's shown. I've always thought it would be nice to
suppress the creation of the popup widget until then too.
You need to log in before you can comment on or make changes to this bug.