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.
Created attachment 153320 [details] [diff] [review] 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.
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
Last Resolved: 14 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.