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
Note that this is an imperfect implementation, in that it doesn't exactly
match the sizing behavior of a truly empty `<select>` element. I've filed
followup bug 1562057 on that. However, the behavior that's implemented
here *does* successfully make us ignore a `<select>`'s contents for sizing
purposes, and it's much better than what we do currently (which is pretty
broken via inheriting a partial `contain:size` implementation from our
parent class, nsBlockFrame).
Differential Revision: https://phabricator.services.mozilla.com/D36253
We used to apply the column container's block size constraint on top of
the available block size in nsColumnSetFrame::ChooseColumnStrategy().
After column-span is enabled, ColumnSet is no longer the outermost
column container frame. We need to apply ColumnSetWrapper's block size
constraint to the available size when creating the ReflowInput for
ColumnSet so that ColumnSet can use it to compute the max column block
size in ChooseColumnStrategy().
This is calculated in nsBlockFrame::ReflowBlockFrame() instead of
nsColumnSetFrame::ChooseColumnStrategy() because we need
BlockReflowInput::mBCoord to determine the remaining block size.
multicol-breaking-004.html is copied and modified from
multicol-breaking-001.html with border-bottom added to test
"box-decoration-break: clone".
Differential Revision: https://phabricator.services.mozilla.com/D31676
This is primarily to fix sizing of 'box-decoration-break:clone' inlines,
but also some 'slice' edge cases by recognizing more break opportunities,
and to improve sizing when BIDI-continuations are involved.
Differential Revision: https://phabricator.services.mozilla.com/D32915
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
That being said, this code is clearly not getting hit, are we 100% sure that
this is interoperable with what WebKit / Blink do?
Differential Revision: https://phabricator.services.mozilla.com/D30830
GetAvailableSpace was renamed to GetFloatAvailableSpace in bug 25888.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D30581
