The previous check rejected any zero-height incomplete fragment
unconditionally, which was too aggressive and broke two cases:
1. A block that is a containing block for absolutely-positioned children must
keep its zero-height fragment as the coordinate origin for those OOF boxes.
This is now guarded by HasAbsolutelyPositionedChildren().
(e.g. out-of-flow-in-multicolumn-029.html)
2. class-c-breakpoint-after-float-001.html: A block with a clear:both child
inside a multicol column can end up with the child pushed by clearance to
exactly the column boundary, leaving it 0px of available space. The child
produces a zero-height incomplete fragment, but its parent still has a
non-zero-height fragment covering the clearance gap. Rejecting the child's
fragment caused the parent's fragment to collapse, losing the class C break
opportunity and the green background over the float area.
More generally, any gap before the child in the parent's fragment (from
clearance, a non-collapsing margin, float avoidance, or preceding siblings)
means the parent fragment is non-zero regardless of this child. The child's
zero-height fragment is only truly useless when it is the very first content
in the fragmentainer with nothing before it.
The refined condition therefore only rejects when fragmentBStart equals
mSpace.BStart(), i.e. the child lands at the very beginning of the available
space. The variable fragmentBStart is introduced to name this quantity
clearly and to avoid recomputing mBCoord - backupContainingBlockAdvance.
Differential Revision: https://phabricator.services.mozilla.com/D292681
When a block is reflowed with zero available block-size in a fragmentainer,
it produces a zero-height fragment with Incomplete status. PlaceBlock now
rejects such fragments so the block is pushed to the next fragmentainer
instead of leaving a useless zero-height fragment.
Genuinely zero-height blocks are unaffected: they have Complete status, so
the new check does not trigger.
Differential Revision: https://phabricator.services.mozilla.com/D283622
The previous check rejected any zero-height incomplete fragment
unconditionally, which was too aggressive and broke two cases:
1. A block that is a containing block for absolutely-positioned children must
keep its zero-height fragment as the coordinate origin for those OOF boxes.
This is now guarded by HasAbsolutelyPositionedChildren().
(e.g. out-of-flow-in-multicolumn-029.html)
2. class-c-breakpoint-after-float-001.html: A block with a clear:both child
inside a multicol column can end up with the child pushed by clearance to
exactly the column boundary, leaving it 0px of available space. The child
produces a zero-height incomplete fragment, but its parent still has a
non-zero-height fragment covering the clearance gap. Rejecting the child's
fragment caused the parent's fragment to collapse, losing the class C break
opportunity and the green background over the float area.
More generally, any gap before the child in the parent's fragment (from
clearance, a non-collapsing margin, float avoidance, or preceding siblings)
means the parent fragment is non-zero regardless of this child. The child's
zero-height fragment is only truly useless when it is the very first content
in the fragmentainer with nothing before it.
The refined condition therefore only rejects when fragmentBStart equals
mSpace.BStart(), i.e. the child lands at the very beginning of the available
space. The variable fragmentBStart is introduced to name this quantity
clearly and to avoid recomputing mBCoord - backupContainingBlockAdvance.
Differential Revision: https://phabricator.services.mozilla.com/D292681
When a block is reflowed with zero available block-size in a fragmentainer,
it produces a zero-height fragment with Incomplete status. PlaceBlock now
rejects such fragments so the block is pushed to the next fragmentainer
instead of leaving a useless zero-height fragment.
Genuinely zero-height blocks are unaffected: they have Complete status, so
the new check does not trigger.
Differential Revision: https://phabricator.services.mozilla.com/D283622
The previous check rejected any zero-height incomplete fragment
unconditionally, which was too aggressive and broke two cases:
1. A block that is a containing block for absolutely-positioned children must
keep its zero-height fragment as the coordinate origin for those OOF boxes.
This is now guarded by HasAbsolutelyPositionedChildren().
(e.g. out-of-flow-in-multicolumn-029.html)
2. class-c-breakpoint-after-float-001.html: A block with a clear:both child
inside a multicol column can end up with the child pushed by clearance to
exactly the column boundary, leaving it 0px of available space. The child
produces a zero-height incomplete fragment, but its parent still has a
non-zero-height fragment covering the clearance gap. Rejecting the child's
fragment caused the parent's fragment to collapse, losing the class C break
opportunity and the green background over the float area.
More generally, any gap before the child in the parent's fragment (from
clearance, a non-collapsing margin, float avoidance, or preceding siblings)
means the parent fragment is non-zero regardless of this child. The child's
zero-height fragment is only truly useless when it is the very first content
in the fragmentainer with nothing before it.
The refined condition therefore only rejects when fragmentBStart equals
mSpace.BStart(), i.e. the child lands at the very beginning of the available
space. The variable fragmentBStart is introduced to name this quantity
clearly and to avoid recomputing mBCoord - backupContainingBlockAdvance.
Differential Revision: https://phabricator.services.mozilla.com/D292681
When a block is reflowed with zero available block-size in a fragmentainer,
it produces a zero-height fragment with Incomplete status. PlaceBlock now
rejects such fragments so the block is pushed to the next fragmentainer
instead of leaving a useless zero-height fragment.
Genuinely zero-height blocks are unaffected: they have Complete status, so
the new check does not trigger.
Differential Revision: https://phabricator.services.mozilla.com/D283622
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
Put all the "is this block a BFC" logic in nsBlockFrame.cpp.
The CLIP_PAGINATED_OVERFLOW flag is also redundant, it can just be "has
non-propagated overflow styles" check in ShouldApplyOverflowClipping(),
and frees another bit.
Shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D203590
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
* Rename `mBreakType` to `mFloatClearType` in nsLineBox and nsReflowStatus and
the methods around it.
* Rename `mBreakType` to `mClear` in nsStyleDisplay.
* Many other method parameters or local variables rename such as from
`aBreakType` to `aClearType`.
Differential Revision: https://phabricator.services.mozilla.com/D158276
aIsAdjacentWithBStart is used to clear the mIsTopOfPage bit for the ReflowInput
argument `aFrameRI`. However, ReflowBlock() already has aState argument to query
IsAdjacentWithBStart(), so there's no need for aIsAdjacentWithBStart argument.
Differential Revision: https://phabricator.services.mozilla.com/D150832
This patch is generated via:
```
rg -l 'BlockReflowInput' layout/ | xargs sed -i 's/BlockReflowInput/BlockReflowState/g'
```
Manual fixes are in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D139439
After this patch, the testcase still triggers soft assertions like
ASSERTION: Placeholder relationship should have been torn down already;
this might mean we have a stray placeholder in the tree.
We have multiple bugs filed for this assertions such as bug 856269.
Differential Revision: https://phabricator.services.mozilla.com/D90760
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
It's straightforward to determine which writing mode is required to pass
to ComputedLogicalMargin() by looking at any subsequent method called on
the margin.
For example, if we see
```
ComputedLogicalMargin().BStartEnd(wm);
```
the writing mode needed to pass to `ComputedLogicalMargin()` is `wm`.
Differential Revision: https://phabricator.services.mozilla.com/D95661
Currently, when using ReflowChildFlags::ApplyRelativePositioning flag in
FinishReflowChild(), we (implicitly) force the callers to pass aWM and
aPos in the same writing-mode as the reflow input, i.e. the child's
writing-mode. This results in an unintuitive LogicalPoint conversion
`mContainerSize - mMetrics.PhysicalSize()` in
nsBlockReflowContext::PlaceBlock().
We should allow the callers to use their preferred aWM and aPos (either
in parent's wm or child's wm), and do the necessary conversion in
FinishReflowChild() (like we did to convert aDesiredSize from
ReflowOutput's wm to aWM).
Also, correct the documentation for aWM in ReflowChild() and
FinishReflowChild(). aWM doesn't need to be the containing frame's
writing-mode. It can be any as long as it is the writing-mode that aPos
is used.
Differential Revision: https://phabricator.services.mozilla.com/D65859
nsBlockDebugFlags.h defines NOISY_BLOCK_DIR_MARGINS, which is used in
nsBlockFrame. Include it in nsBlockReflowContext.cpp so that when
NOISY_BLOCK_DIR_MARGINS is defined, the log is printed in
nsBlockReflowContext.cpp as well.
Remove unused NOISY_MAX_ELEMENT_SIZE and REALLY_NOISY_MAX_ELEMENT_SIZE.
Differential Revision: https://phabricator.services.mozilla.com/D43903
Note that this changes the writing mode used for the SetSize call from
the parent's to the child's. (This controls what position is kept
constant.) I don't think this changes behavior at all, since there is
(for this caller) a SetRect call just below.
Differential Revision: https://phabricator.services.mozilla.com/D40566
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
This is a follow-up for Part 1. I find all the candidates by running the
following command under layout/, and manually replace them.
ag -A 1 reflow$ | ag -B 1 state
Differential Revision: https://phabricator.services.mozilla.com/D27162
Many of the modifications are guarded by #ifdefs. I verify them locally
by manually define them in nsBlockDebugFlags.h and nsLinelayout.cpp.
Note that I replace "mFrame" with "frame" in lines guarded by
NOISY_BLOCK_DIR_MARGINS in nsBlockFrame.cpp because they were
incorrectly renamed in Bug 1277129 Part 6a.
https://hg.mozilla.org/mozilla-central/rev/a70b04f074fc
Differential Revision: https://phabricator.services.mozilla.com/D17733
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
It's good to save a copy constructor call.
Also, make nsBlockFrame::SplitFloat() return void because the only
caller (BlockReflowInput::FlowAndPlaceFloat()) doesn't check its return
value, and (more importantly) because it only ever returns NS_OK.
MozReview-Commit-ID: 9LmDCXd7xGS
Hiroyuki Ikezoe