Open
Bug 983581
Opened 11 years ago
Updated 2 years ago
Clean up handling of columns transitioning from balanced to non-balanced due to overflow
Categories
(Core :: Layout, defect)
Tracking
()
NEW
People
(Reporter: roc, Unassigned)
Details
Attachments
(1 file)
(deleted),
patch
|
MatsPalmgren_bugz
:
review-
|
Details | Diff | Splinter Review |
It's broken. The testcase of bug 983465 comment #0, with that bug fixed, shows that we don't correctly break out of balanced mode and create overflowing columns in the horizontal direction.
Reporter | ||
Comment 1•11 years ago
|
||
Unfortunately I can't create a reduced testcase. Hmm.
Reporter | ||
Comment 2•11 years ago
|
||
Attachment #8391119 -
Flags: review?(matspal)
Comment 3•11 years ago
|
||
Comment on attachment 8391119 [details] [diff] [review]
fix
Is this the right patch? It fails to compile:
nsColumnSetFrame.cpp:325:10: error: no member named 'mComputedMaxHeight' in 'nsColumnSetFrame::ReflowConfig':
config.mComputedMaxHeight = computedMaxHeight;
^~~~~~~~~~~~~~~~~~
Nit: nsSplittableFrame::GetEffectiveComputedMaxHeight (and same also for
GetEffectiveComputedHeight):
> if (aConsumedHeight == NS_INTRINSICSIZE) {
> aConsumedHeight = GetConsumedHeight();
> }
>
> height -= aConsumedHeight;
>
> if (aConsumedHeight != 0 && aConsumedHeight != NS_INTRINSICSIZE) {
> // We just subtracted our top-border padding, since it was included in the
GetConsumedHeight() always return a real height, not NS_INTRINSICSIZE,
so the "&& aConsumedHeight != NS_INTRINSICSIZE" seems redundant.
Also, "top-border padding" doesn't read very well, perhaps "top border+padding"?
or "top-border/padding"?
Comment 4•11 years ago
|
||
Comment on attachment 8391119 [details] [diff] [review]
fix
I'll wait for a new patch before reviewing this further.
Attachment #8391119 -
Flags: review?(matspal) → review-
Reporter | ||
Updated•9 years ago
|
Assignee: roc → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•