Consolidate min/max-width/height handling

NEW
Unassigned

Status

()

13 years ago
24 days ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor])

(Reporter)

Description

13 years ago
Need to consolidate handling of min-width, etc.  Things to keep in mind as this is done:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsGfxScrollFrame.cpp&rev=3.267&mark=470-484#462 -- last part should be looking at the min width.

Carefully differentiating between "specified" widths/heights and "computed" (based on the equations in the CSS spec or based on intrinsic sizes) ones.  Box-sizing applies differently to the two.
(Reporter)

Updated

13 years ago
Flags: blocking1.9a2?
Whiteboard: [reflow-refactor]
(Reporter)

Comment 1

12 years ago
Testcase this bug should fix:

<select style="width: 100px" multiple>
<option>aaa</option>
</select><br>
<select style="width: 100px; min-width: 100px" multiple>
<option>aaa</option>
</select>

Right now the selects end up different sizes, because ComputeInsideBorderSize() calls ApplyMinMaxConstraints() on an mComputedWidth, which just doesn't do anything resembling the right thing.  I think we want to fix that and to use ApplyMinMaxConstraints in the reflow state itself as needed (e.g. in current callers nsHTMLReflowState::AdjustComputedWidth and nsHTMLReflowState::AdjustComputedHeight?).
Flags: blocking1.9a2? → blocking1.9-

Updated

29 days ago
Product: Core → Core Graveyard
(Assignee)

Updated

24 days ago
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.