Closed
Bug 251510
Opened 20 years ago
Closed 20 years ago
overflow (and thus scrolling) broken on comboboxes and listboxes (selects)
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dbaron, Assigned: roc)
References
Details
(Keywords: regression, smoketest)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
(It's bug 151375 that I'm blaming.)
Reporter | ||
Comment 2•20 years ago
|
||
(although without proof)
Assignee | ||
Comment 3•20 years ago
|
||
I agree that it's probably us...
*** Bug 251558 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 5•20 years ago
|
||
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)
Assignee | ||
Comment 7•20 years ago
|
||
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.
Reporter | ||
Updated•20 years ago
|
Summary: overflow broken on comboboxes and listboxes → overflow (and thus scrolling) broken on comboboxes and listboxes (selects)
Comment 9•20 years ago
|
||
Is Bug 251586 a dupe of this one? This also happends in latest Firefox branch
build and suite 1.7.1 with classic.
Reporter | ||
Comment 10•20 years ago
|
||
No.
Assignee | ||
Comment 11•20 years ago
|
||
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
Comment 12•20 years ago
|
||
*** Bug 251684 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 13•20 years ago
|
||
This was fixed by backing out the outline patch.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 14•20 years ago
|
||
*** Bug 251817 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** 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.
Description
•