Closed Bug 251510 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

x86
Linux
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: roc)

References

Details

(Keywords: regression, smoketest)

Attachments

(1 file)

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.
(It's bug 151375 that I'm blaming.)
(although without proof)
I agree that it's probably us...
*** Bug 251558 has been marked as a duplicate of this bug. ***
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.
Status: NEW → ASSIGNED
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)
Are you SURE? that seems incredibly surprising to me
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.
Summary: overflow broken on comboboxes and listboxes → overflow (and thus scrolling) broken on comboboxes and listboxes (selects)
Is Bug 251586 a dupe of this one? This also happends in latest Firefox branch
build and suite 1.7.1 with classic.
No.
Attached patch fixSplinter Review
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.
Assignee: nobody → roc
*** Bug 251684 has been marked as a duplicate of this bug. ***
This was fixed by backing out the outline patch.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
*** Bug 251817 has been marked as a duplicate of this bug. ***
*** Bug 252701 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.