251510 - overflow (and thus scrolling) broken on comboboxes and listboxes (selects)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

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

In my build from this evening, overflow on comboboxes and list boxes is broken.

Steps to reproduce:
 1. load this page
 2. examine "Target Milestone" dropdown
 3. load http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser
 4. examine "Component" box

Actual results:
 2. Target milestone has no scrollbar and ends with mozilla0.8
 4. Component box ends with "Chatzilla" and scrollbar shows no room to scroll

Expected results:
 2. Target milestone dropdown is scrollable and shows recent milestones.
 4. Component box is scrollable and shows lots of components, many of which
start with "X"

I blame the aaronl + roc checkin for outlines that I reviewed.

Comment 1

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

(It's bug 151375 that I'm blaming.)

Comment 2

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

(although without proof)

Comment 3

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

I agree that it's probably us...

Comment 4

[R.K.Aa.]

*** Bug 251558 has been marked as a duplicate of this bug. ***

Comment 5

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

Okay, the problem is right here:

http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsBox.cpp#568

This is being called on the nsBoxToBlockAdaptor for the nsAreaFrame holding the
options, and that's wiping out the overflow area of the nsAreaFrame.

My solution is to remove the FinishAndStoreOverflow from there and pass that
burden to the callers. Most callers of SetBounds will eventually do a Layout or
SyncLayout on the same box that will compute the overflow area, so they're taken
care of. Some other callers are just moving the box, so the overflow area
doesn't need to change. The remaining places are just a couple of places that
want to remove any overflow area because they're trying to collapse the box or
have somehow taken the overflow area into account already. I'll attach a patch.

Comment 6

[R.K.Aa.]

i just did this:
cvs update -j1.15 -j1.14
mozilla/xpfe/global/resources/content/bindings/scrollbar.xml

and it cured the regression. (a checkin yesterday for bug 250553)

Comment 7

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

Are you SURE? that seems incredibly surprising to me

Comment 8

[R.K.Aa.]

backed out in one tree and listboxes worked again - i thought - but i was not
able to repeat that in a second tree. False alarm - sorry.

Comment 9

[José Jeria]

Is Bug 251586 a dupe of this one? This also happends in latest Firefox branch
build and suite 1.7.1 with classic.

Comment 10

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

No.

Comment 11

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

Attachment: fix

This should fix it. The patch does what I mentioned before to fix SetBounds. It
also catches a situation where we try to recompute the overflow area of a
boxToBlockAdaptor which doesn't work because it has no box children.

Comment 12

[Bill Mason]

*** Bug 251684 has been marked as a duplicate of this bug. ***

Comment 13

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

This was fixed by backing out the outline patch.

Comment 14

[José Jeria]

*** Bug 251817 has been marked as a duplicate of this bug. ***

Comment 15

[R.K.Aa.]

*** Bug 252701 has been marked as a duplicate of this bug. ***