In bug 1844755, a bunch of the time is spent allocating initial values.
There used to be more document-dependent initial values before
bug 1834487, but now that's only about default-font and direction.
This improves the situation by sharing initial structs that don't depend
on the document.
Differential Revision: https://phabricator.services.mozilla.com/D184256
Make the computed value of border-like properties app units (which is
effectively what happens in Gecko already), and clamp at computed value
time.
Differential Revision: https://phabricator.services.mozilla.com/D179481
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
A top-level multicol in a paginated context can be fragmented. We should use the
same logic to set the `mIsTopOfPage` bit as if the multicol is a nested one.
WARNING: loading the testcase without this patch can trap Firefox in an infinite
loop.
Differential Revision: https://phabricator.services.mozilla.com/D177578
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
The testcase was originated from D169662 written by Daniel Holbert, which was
discovered by fuzzer in bug 1756202.
Note that the crashtest that hangs the browser might not always be reproducible
locally. It is reproducible on "Linux 18.04 x64 WebRender tsan opt" build on
try.
Differential Revision: https://phabricator.services.mozilla.com/D170532
The only difference between multicol-nested-030.html and
multicol-nested-031.html is the `column-fill` property on the outer column.
WARNING: loading 030.html and 031.html without this patch can trap Firefox in
infinite loops.
Differential Revision: https://phabricator.services.mozilla.com/D169005
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
RemoveFramesAfter and ExtractTail have similar purpose, so we really should keep
one of them to avoid confusion.
They have the following minor differences:
1. RemoveFramesAfter() keeps aFrame in the list, while ExtractTail() returns it.
2. If aFrame is empty, RemoveFramesAfter() returns the entire list, while
ExtractTail returns an empty list.
It's more convenient for the existing callers to use the RemoveFramesAfter(), so
ExtractTail is unneeded.
After this patch, both RemoveFramesAfter() and RemoveFramesBefore() return the
entire list if aFrame is nullptr.
Rename RemoveFramesAfter() to TakeFramesAfter() for symmetry with
TakeFramesBefore().
This change shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158807
With part 1, ReflowChildren and ReflowColumns are identical except for the
constness of the ReflowConfig. I choose to remove ReflowChildren because
ReflowColumns is more meaningful and keeping it requires less change to the
existing code.
Differential Revision: https://phabricator.services.mozilla.com/D154428
Remove the flag because it doesn't serve its purpose for current multicolumn
frame hierarchy (i.e. after we introduce ColumnSetWrapperFrame). Nowadays, we
limit the column's block-size with the column container's block-size and
max-block-size in [1]. If the column container has content which exceeds its
max-block-size, we are going to give up column balancing and reach [2] after the
first iteration in the column balancing `while` loop in FindBestBalanceBSize().
However, the flag can still be set in cases with absurd `nscoord` values, so
this patch still changes the behavior. For example, in crashtests with bogus
sizes such as 673770.html,
```
contentBEnd > aReflowInput.mCBReflowInput->ComputedMaxBSize() && aConfig.mIsBalancing
```
can still be true when `contentBEnd` is greater than `nscoord_MAX`. In such
cases, we might spend extra iterations in column balancing. Other than that, our
rendering shouldn't have perceived behavior change.
[1] https://searchfox.org/mozilla-central/rev/6a37a2ab9328bec6a29f688d1b2fba6974d34905/layout/generic/nsBlockFrame.cpp#3834-3844
[2] https://searchfox.org/mozilla-central/rev/6a37a2ab9328bec6a29f688d1b2fba6974d34905/layout/generic/nsColumnSetFrame.cpp#1145-1162,1169-1173
Differential Revision: https://phabricator.services.mozilla.com/D154427
According to `nsContainerFrame::ShouldAvoidBreakInside`, we allow a frame to
break from inside when it is at the top of page/column, i.e. when `mIsTopOfPage`
is true.
This patch allows the content at the top of the column to honor the
break-inside:avoid during column balancing, so it can now propagate the
break-before status to nsColumnSetFrame if it needs to report such status.
We don't need to worry about disallowing an break-inside:avoid content from
breaking will trap the column balancing algorithm forever. If the content's
block-size is larger than the column container's available content-box
block-size, then the column balancing algorithm will give up and fill the
columns sequentially at
https://searchfox.org/mozilla-central/rev/4f2984be127d2e7c788cf1848d63dca63022beec/layout/generic/nsColumnSetFrame.cpp#1146-1162
The reference files are modified to reflect the rendering as of this patch. Note
that browsers do not agree on the rendering of `1420528-1.html`. Before this
patch, our rendering is the same as Chrome by placing "Spacer" in the first
column, but now we agree with webkit by placing it in the second column.
The multicol in `611574-2.html` is used for visual separation of subtests. I
change it from column balancing to fill to workaround bug 1784002.
Differential Revision: https://phabricator.services.mozilla.com/D154048
According to `nsContainerFrame::ShouldAvoidBreakInside`, we allow a frame to
break from inside when it is at the top of page/column, i.e. when `mIsTopOfPage`
is true.
This patch allows the content at the top of the column to honor the
break-inside:avoid during column balancing, so it can now propagate the
break-before status to nsColumnSetFrame if it needs to report such status.
We don't need to worry about disallowing an break-inside:avoid content from
breaking will trap the column balancing algorithm forever. If the content's
block-size is larger than the column container's available content-box
block-size, then the column balancing algorithm will give up and fill the
columns sequentially at
https://searchfox.org/mozilla-central/rev/4f2984be127d2e7c788cf1848d63dca63022beec/layout/generic/nsColumnSetFrame.cpp#1146-1162
The reference files are modified to reflect the rendering as of this patch. Note
that browsers do not agree on the rendering of `1420528-1.html`. Before this
patch, our rendering is the same as Chrome by placing "Spacer" in the first
column, but now we agree with webkit by placing it in the second column.
Differential Revision: https://phabricator.services.mozilla.com/D154048
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
In nsReflowStatus::UpdateTruncated(), mTruncated can be true only when
mIsTopOfPage is false. However, when we reflow -moz-column-content, we always
set mIsTopOfPage to true. Therefore, IsTruncated() always returns false, i.e.
`!IsTruncated()` is always true.
Differential Revision: https://phabricator.services.mozilla.com/D151460
