Flex containers do not need the `alignCB` tweak for table frames in
`ReflowInput::InitConstraints`, so I remove the comment, and improve it so that
we don't need to call `alignCB->GetParent()` multiple times.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D196257
The bug occurs because some abspos children are split, but not being reflowed
again in the last column balancing reflow where the available block-size of the
last column might be unconstrained.
This patch makes the callers utilizing `ReflowInput::ShouldReflowAllKids()`
always reflow in the last column balancing reflow to ensure the correctness of
the layout.
Note: the `mIsInLastColumnBalancingReflow` flag is inheriting from parent to
child reflow input, but it will stop at the nested `nsColumnSetFrame` because
the nested one will create its own `ReflowConfig::mIsLastBalancingReflow` and
assign that flag when creating the reflow input for the children.
Differential Revision: https://phabricator.services.mozilla.com/D195945
A flex item's block-size may grow as a result of fragmentation. If we detect its
block-size is allowed to grow, then we use 'auto' block-size in the
`StyleSizeOverrides` when creating a ReflowInput, and treat its original
block-size as the min-size (as a lower bound).
Differential Revision: https://phabricator.services.mozilla.com/D188532
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
The border property is just useless, we only use it to store stuff
across border style changes, which makes zero sense because we clear it
when we start reflowing.
Differential Revision: https://phabricator.services.mozilla.com/D191177
The containing block's block-size (`blockContentSize.BSize(wm)`) can be
unconstrained if the block has `position:relative` at the time we call the
`CalculateBorderPaddingMargin()`. That triggers the warning further down in the
stack in `ComputeCBDependentValue`.
However, the percentage margin and padding should resolve against the containing
block's inline-size rather than the block-size. Hence this patch.
Differential Revision: https://phabricator.services.mozilla.com/D174340
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
The expectations in page-name-propagated-003.html have turned out to be wrong
now that we have more correct abspos support.
We also need to check for placeholders in block reflow to actually support
named pages causing breakpoints where in-flow frames meet placeholders for out-
of-frame siblings.
Differential Revision: https://phabricator.services.mozilla.com/D170821
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705
nsColumnSetFrame can reflow its last column in an unconstrained available
block-size to measure the total block-size of the content [1]. This patch adds a
helper method in ReflowInput for that.
For flex items in a fragmented context, we *cannot* skip its final reflow
because fragmentation might grow its block-size if there's any force break in
it (bug 1663079), or if it has repeated table header/footer (bug 1744363).
This patch doesn't change observable behavior for now. Before this patch, we may
skip an item's final reflow if it is in a flex container's continuation that is
in the last column with an unconstrained available block-size. As of this patch,
the item will be reflowed. This is a partial step towards fixing the above bugs
where the item's block-size may grow.
[1] https://searchfox.org/mozilla-central/rev/daf613efc5c358f3a94961d73b90472c00703838/layout/generic/nsColumnSetFrame.cpp#614-621
Differential Revision: https://phabricator.services.mozilla.com/D167207
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
-moz-column-content is the anonymous block under nsColumnSetFrame, and it
doesn't have any margin in UA stylesheet, so we don't need to call
CalculateBlockSideMargins() to compute its auto margin.
The assertion added in Bug 1782602 is triggered by the testcase because bogus
size leads to negative available inline-size, and CalculateBlockSideMargins()
can compute non-zero margin.
Differential Revision: https://phabricator.services.mozilla.com/D165930
Make it work as a min-size everywhere rather than only handling it in
nsIFrame::ComputeSize.
This is more similar to what XUL code does. In particular, it makes
makes it work for elements that don't have a definite size in
ComputeSize (like flex containers).
For web-exposed widgets this only matters for <input type=color> and
<input type=range>, which are the only exposed widgets that return a
minimum size that return a minimum size. This patch makes the minimum
size honored for `<input type="color" style="height: auto">`. Add a test
for that (though we might want to change it to match other browsers).
Without this fix, min/max/close buttons on Linux are zero-height with
flex emulation, because we fail to account for their minimum
widget-imposed size.
This allows us to remove the special case in nsFlexContainerFrame too,
since that should be handled by ReflowInput correctly now.
Differential Revision: https://phabricator.services.mozilla.com/D158612
This will allow this function to eventually return an appropriate value
depending on whether or not content is skipped via `content-visibility:
auto`. This change also starts looking directly at whether
content-visibility is skipping content or not, which should make it
compatible with a future `content-visibility: auto` implementation.
Differential Revision: https://phabricator.services.mozilla.com/D157831
This is a hack, sorta, similar to Chromium's:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;l=356;drc=312b74e385e6aba98ab31fd911238c0dc16b396c
except at computed-value rather than used-value time, because it's both
simpler to reason about and prevents lying in the computed style.
This fixes the relevant test-case, and matches closer what Chromium does,
by not creating anonymous flex items for all elements inside the
line-clamp context.
The behavior change is covered by the test changes. I had to also fix a
couple pre-existing bugs that were caught by tests, now that the
line-clamped block is the -webkit-box-styled element rather than an anonymous
flex item (and thus now had padding).
Depends on D155180
Differential Revision: https://phabricator.services.mozilla.com/D155181
Use a more precise, grid-specific flag to avoid applying grid stretching
etc, and pass an unconstrained block size instead for baseline alignment
measuring, which will cause us to interpret relative sizes as auto.
This shouldn't cause any behavior change, but is a prerequisite
necessary for bug 1609403 (where we don't always want definite sizes
being ignored in measuring reflows for baseline alignment). It's also a
bit clearer, IMO.
Differential Revision: https://phabricator.services.mozilla.com/D155178
While I'm here, rename the local variable `styleMargin` to `margin` to make the
naming consistent with the `padding` naming in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D152203
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
