Without this patch, the `CHECK_BLOCK_AND_LINE_DIR` soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.
Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.
Add reftests to verify that BFC bits are added to the child block if the
parent and child has the same block-direction, but different sideways
bit; also, add reftests to ensure that "text-orientation: sideways"
doesn't add BFC bits.
Differential Revision: https://phabricator.services.mozilla.com/D45912
Without this patch, the `CHECK_BLOCK_AND_LINE_DIR` soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.
Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.
Add reftests to verify that BFC bits are added to the child block if the
parent and child has the same block-direction, but different sideways
bit; also, add reftests to ensure that "text-orientation: sideways"
doesn't add BFC bits.
Differential Revision: https://phabricator.services.mozilla.com/D45912
Frames split by column-span are linked together by non-fluid
continuations. We want GetLogicalSkipSides() to recognize that. The
documentation in nsIFrame::GetLogicalSkipSides() already
uses *continuation* rather than *in-flow*, so no need to adjust the
wording.
However, after patching GetLogicalSkipSides(), the first column-content
after a column-span split starts to skip the block-start side because it
has a previous continuation. We want the content in the first column to
consider applying its block-start margin. Hence the modification in
BlockReflowInput's constructor. (Note that the first column-content is
always a block-start margin-root, which is fixed in the previous part.)
This is necessary to avoid breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-margin-bottom-001.xht
In multicol-span-all-children-height-006.html, add "margin-top: 1em;" to
the container to expose the bug if we still check GetPrevInFlow() rather
than GetPrevContinuation() when computing applyBStartMargin in
nsBlockFrame::ReflowBlockFrame().
Differential Revision: https://phabricator.services.mozilla.com/D43905
This patch changes behavior only if column-span is enabled. It fixes a
lot of fuzzing test cases which will be added in the next part.
It changes the column balancing behavior in the following ways.
1) By using unconstrained block-size to measure the last column in the
first balancing iteration, we can guarantee that mKnownFeasibleBSize
has the correct feasible block-size.
2) Always reflow one more time if the content cannot fit in the
available content block-size. Due to 1), the content (last column)
always returns fully complete in the first balancing iteration even if
it's in an inner column with a constrained available block-size. We need
to reflow again to get the correct *incomplete* reflow status so that
the outer column can create next-in-flows for the inner column.
3) ColumnSet gives up balancing only when ColumnSetWrapper is running
out of block-size. When a ColumnSetWrapper has constrained block-size,
i.e. it's in a fragmentation context like pages or nested columns, we
prioritize fragmenting ColumnSetWrapper over creating overflow columns
within the nsColumnSet.
Differential Revision: https://phabricator.services.mozilla.com/D43128
Every time I read the code, the name `blockReflowInput` makes me think
the variable is an instance of `BlockReflowInput`, but it is not.
Differential Revision: https://phabricator.services.mozilla.com/D43127
The flag's original form `mUnconstrainedHeight` was added in
nsBlockReflowState.h in
e580331b37
Nowadays, we often check available block-size in reflow directly in nsBlockFrame.
Differential Revision: https://phabricator.services.mozilla.com/D42733
Before bug 1411422, a ::-moz-column-content has height:100%, so it could
go into this path if ColumnSet's available block-size is unconstrained.
However, after bug 1411422, height:100% was removed for
::-moz-column-content. That is, its computed block-size is
unconstrained, so it can't go into this path. This applies regardless of
whether column-span is enabled or not.
Differential Revision: https://phabricator.services.mozilla.com/D42708
Run broken-column-rule-1.html with column-span enabled because it was
regressed by Bug 1548100 Part 2, but fixed by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D41907
We always pass consumed block-size into BlockReflowInput's constructor
in nsBlockFrame::Reflow(). By making mConsumedBSize a constant, its
assessor method becomes redundant.
Update the documentation to reflect the reality that ConsumedBSize()
accumulates content block-size from all previous *continuations*, which
was done in Bug 1506293 Part 2.
Differential Revision: https://phabricator.services.mozilla.com/D41906
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
We want mHasColumnSpanSiblings to propagate to all the
continuations (both fixed ones or fluid ones) in nsFrame::Init() so that
we don't need to traverse all the way to FirstInFlow() for the bit in
nsBlockFrame::ComputeFinalBSize().
For the last ColumnSet or the last non-column-span wrapper, we'll need
to unset the bit for them manually after constructing them.
Differential Revision: https://phabricator.services.mozilla.com/D40761
This patch lets nsBlockFrame keep its NS_FRAME_FIRST_REFLOW bit a bit
longer, for the full duration of its first reflow, so that in the future
we may add more code to inspect it if needed before nsFrame::DidReflow()
clears it.
Differential Revision: https://phabricator.services.mozilla.com/D40512
This depends on the line state stored in the previous patch, and will be
used in the following patch.
I'm passing this information through the reflow input here, rather than
doing an extra pass over the frame tree in the following patch, because
I believe it's substantially better for memory locality during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D40275
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
On its own (without the previous patch), this fixes bug 1406291.
Combined with the previous patch, this patch fixes this bug (bug
1420528) when column-span is not enabled (today's configuration), and
also fixes 1411799.
Differential Revision: https://phabricator.services.mozilla.com/D39818
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
In frame construction, a block can be split by column-spans into several
fragments and each of the fragments is chained together by non-fluid
continuations. Later in reflow, each fragment can create its own fluid
continuations due to reasons such as the constraint of its available
block-size.
The main idea of this patch is that we calculate the block's final
block-size by shrinkwrapping the children for every fragment except for
those fluid continuations after the final column-span. To do that, we
need to correctly tag each non-column-span-wrappers
nsIFrame::HasColumnSpanSiblings() except the last one.
We also need to modify nsSplittableFrame::ConsumedBSize() so that it
includes the block-size for both fluid and non-fluid continuations.
Differential Revision: https://phabricator.services.mozilla.com/D38124
As described in https://bugzilla.mozilla.org/show_bug.cgi?id=1562122#c5,
this precomputed argument is not our children's block-size, but is the
block-end edge of children because aState.mBCoord is initialized as our
border-padding block-start in BlockReflowInput's constructor.
I also delete the sentence "The final block-size that is used in
aMetrics will be set ..." because this is the implementation details of
this function, and is likely to become inaccurate after considering the
block split by column-span.
Depends on D37625
Differential Revision: https://phabricator.services.mozilla.com/D37626
Because aStatus is also used as an output argument, caching aStatus as
our children's reflow status can and make the logic that morphs aStatus
to our reflow status easier to follow. And this helps the patch I'm
going to add for computing the block-size for column-span split.
Depends on D37624
Differential Revision: https://phabricator.services.mozilla.com/D37625
We usually use reference to manipulate nsReflowStatus like in Reflow().
The documentation for aStatus needs edit, and is done in next part.
Depends on D37623
Differential Revision: https://phabricator.services.mozilla.com/D37624
ComputeFinalBSize() doesn't need to modify the final inline-size, so we
don't need to pass the entire LogicalSize into it.
Also, aReflowInput.AvailableBSize() is used multiple times. Cache it to
shorten some statements.
Differential Revision: https://phabricator.services.mozilla.com/D37623
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
After the deleted logic
```
aFinalSize.BSize(wm) =
std::max(aReflowInput.AvailableBSize(), aContentBSize);
```
aStatus changes to incomplete, so it computes the same thing again.
Differential Revision: https://phabricator.services.mozilla.com/D36290
No need to call GetEffectiveComputedBSize() twice.
Also, calling aState.ConsumedBSize() instead of using
aState.mConsumedBSize directly because the accessor function caches
mConsumedBSize properly when it is called the first time.
Differential Revision: https://phabricator.services.mozilla.com/D36289
This patch only moves the logic, and rename some variables. More
clean-up follows.
Note in the middle of ComputeFinalBSize(), ShouldAvoidBreakInside() can
do early return under the condition that aStatus is complete. The logic
moved in this patch is executed only when aStatus is *incomplete*, so no
behavior is changed after applying this change.
Differential Revision: https://phabricator.services.mozilla.com/D36288
