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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Removing the align="left" from the table cell in this testcase seems to fix the
bug.

Comment 2

[Martijn Wargers (dead)]

Ok, this regressed between 2005-06-15 and 2005-06-17:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-15+05%3A00%3A00&maxdate=2005-06-17+10%3A00%3A00&cvsroot=%2Fcvsroot
Maybe because of the checkin in this period of bug 290428?

Comment 3

[Martijn Wargers (dead)]

I forgot to say, this can only be seen with bfcache turned off.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is actually broken in 2005-06-16-06 builds too.  So the bonsai range is
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-15+05%3A00%3A00&maxdate=2005-06-16+07%3A00%3A00&cvsroot=%2Fcvsroot

Possible causes: bug 296337, bug 64510.

I see this on Linux too.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm guessing 64510 based on the align="left".

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did it happen with align="right" before that checkin?

Comment 7

[Martijn Wargers (dead)]

Attachment: Testcase2, now using align=right

> Did it happen with align="right" before that checkin?
Yes, the regression period for that is between 2004-09-11 and 2004-09-13:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-11+08%3A00%3A00&maxdate=2004-09-13+10%3A00%3A00&cvsroot=%2Fcvsroot

Possibly a regression from bug 257916?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

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!

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 190067 [details] [diff] [review]
fix

need approval for this history bug (blocker)

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Surprisingly, it looks like this reduced Tp on btek a bit.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.