`ComputeISizeValue()` used to take `StyleSizeOverrides`, but
This patch reflects the fact that intrinsic inline size value such as
'min-content', 'max-content', etc. can be resolved via a definite block size and
a preferred aspect-ratio.
For the callers in `nsIFrame::ComputeSize()` and
`nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`, we can pass the
`styleBSize` and `aspectRatio` that have considered the size overrides.
Also, simplify `ComputeISizeValueFromAspectRatio()` so that it can be reused in
other places. We'll adapt more callers in the next part. Note that the `aFlags`
parameter is unused, so it is removed.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215294
When computing a hypothetical position for a fixed-pos element, we first compute
its position relative to the nearest block container `containingBlock`, and then
get the offset between `containingBlock` and the actual fixed-pos containing
block, i.e. the ViewportFrame.
However, using the ViewportFrame's origin (0,0) is incorrect. The fixed-pos
element's origin should exclude the scrollbar or scrollbar-gutter area [1].
We've fixed the containing block's origin for ViewportFrame (bug 728807), which
is used when reflowing the fixed-pos frames. The bug fixed the fixed-pos
element's position when `inset` value is specified. In this patch, when
computing the hypothetical position, we should also adjust the offset to the
containing block's origin for ViewportFrame so that the origin doesn't include
the scrollbar-gutter area, because we'll add the containing block's origin after
we reflow the fixed-pos frame at [2]. Failing to exclude the scrollbar-gutter
will cause us to shift the fixed-pos position by the scrollbar-gutter twice if
the element does use the hypothetical position as the final position
[1] A recent CSSWG resolution changed this so that top-layer or fullscreen
fixed-pos element cover the scrollbar or scrollbar-gutter. This is bug 1874091.
[2] https://searchfox.org/mozilla-central/rev/94f839e924ba6c69f3e0d062d4c6cc4fee7cad5b/layout/generic/nsAbsoluteContainingBlock.cpp#850-853
Differential Revision: https://phabricator.services.mozilla.com/D213345
Remove unused `nsPresContext` and `LayoutFrameType` parameters in
`InitAbsoluteConstraints()` and `CalculateHypotheticalPosition()` (except for
one usage in `NS_ASSERTION`).
Improve the documentation for `CalculateHypotheticalPosition()` and delete the
nearly the same documentation before its definition in ReflowInput.cpp.
In `InitAbsoluteConstraints()`, we don't need to initialize the `offsets` local
variable via `ComputedLogicalOffsets()` since this is the function computing the
offset, and we'll set the four sides of `offsets` later in the function.
Differential Revision: https://phabricator.services.mozilla.com/D213313
When computing a hypothetical position for a fixed-pos element, we first compute
its position relative to the nearest block container `containingBlock`, and then
get the offset between `containingBlock` and the actual fixed-pos containing
block, i.e. the ViewportFrame.
However, using the ViewportFrame's origin (0,0) is incorrect. The fixed-pos
element's origin should exclude the scrollbar or scrollbar-gutter area [1].
We've fixed the containing block's origin for ViewportFrame (bug 728807), which
is used when reflowing the fixed-pos frames. The bug fixed the fixed-pos
element's position when `inset` value is specified. In this patch, when
computing the hypothetical position, we should also adjust the offset to the
containing block's origin for ViewportFrame so that the origin doesn't include
the scrollbar-gutter area, because we'll add the containing block's origin after
we reflow the fixed-pos frame at [2]. Failing to exclude the scrollbar-gutter
will cause us to shift the fixed-pos position by the scrollbar-gutter twice if
the element does use the hypothetical position as the final position
[1] A recent CSSWG resolution changed this so that top-layer or fullscreen
fixed-pos element cover the scrollbar or scrollbar-gutter. This is bug 1874091.
[2] https://searchfox.org/mozilla-central/rev/94f839e924ba6c69f3e0d062d4c6cc4fee7cad5b/layout/generic/nsAbsoluteContainingBlock.cpp#850-853
Differential Revision: https://phabricator.services.mozilla.com/D213345
Remove unused `nsPresContext` and `LayoutFrameType` parameters in
`InitAbsoluteConstraints()` and `CalculateHypotheticalPosition()` (except for
one usage in `NS_ASSERTION`).
Improve the documentation for `CalculateHypotheticalPosition()` and delete the
nearly the same documentation before its definition in ReflowInput.cpp.
In `InitAbsoluteConstraints()`, we don't need to initialize the `offsets` local
variable via `ComputedLogicalOffsets()` since this is the function computing the
offset, and we'll set the four sides of `offsets` later in the function.
Differential Revision: https://phabricator.services.mozilla.com/D213313
This removed one is just forwarding the call to nsIFrame, and used internally
within ReflowInput.
While I'm here, rename local variables `inside*` and `outside*` to make them
clearer.
Differential Revision: https://phabricator.services.mozilla.com/D212509
`ComputeBSizeDependentValue()` is the same as `ComputeCBDependentValue()` except
for the assertion, and existing callers of it are passing containing block's
block-size, which indicates that calling `ComputeCBDependentValue()` might make
more sense.
Differential Revision: https://phabricator.services.mozilla.com/D212507
The `IsReplacedWithBlock()` method is used only in
`ShouldApplyOverflowClipping()`, which determines the overflow clip axes. Since
we've already enumerated the frame types that need overflow clipping, we can
just add more types that had `ReplacedContainsBlock` flag to the switch-cases
and remove the flag.
Differential Revision: https://phabricator.services.mozilla.com/D212199
A sticky element gets its offsets computed in
`StickyScrollContainer::ComputeStickyOffsets()`, and that is invoked in
`UpdateSticky()` *after* we reflow the scrolled frame in
`nsHTMLScrollFrame::Reflow()`.
Therefore, in the initial reflow of the sticky element (where we haven't fully
reflow its scrolled frame container), `ComputePosition()` does nothing because
the elements doesn't get its offsets computed yet [2].
In an incremental reflow of a sticky element, the code can produce wrong sticky
position, because `ComputePosition()` and its helper `ComputeStickyLimits()` use
an obsoleted scrollable overflow of the scrolled frame [3] or an obsoleted
offset [4] from the last reflow. For example, in the testcases the sticky offset
has a percentage value and its basis is changed (e.g. scroll container's width
or height changed).
To summarize, computing sticky position prematurely leads to issues, and doesn't
always prevent unnecessary overflow updates, both in the initial reflow and some
incremental reflow cases. Thus, this patch removes it, and always let the scroll
container update the positions for all sticky elements.
[1] https://searchfox.org/mozilla-central/rev/6121b33709dd80979a6806ff59096a561e348ae8/layout/generic/nsGfxScrollFrame.cpp#1624
[2] To be precise, `ComputedOffsetProperty()` is not set, and will bail out in
StickyScrollContainer::ComputeStickyLimits().
[3] https://searchfox.org/mozilla-central/rev/6121b33709dd80979a6806ff59096a561e348ae8/layout/generic/StickyScrollContainer.cpp#198
[4] https://searchfox.org/mozilla-central/rev/6121b33709dd80979a6806ff59096a561e348ae8/layout/generic/StickyScrollContainer.cpp#161-162
Differential Revision: https://phabricator.services.mozilla.com/D208172
The two macros are only used in ReflowInput.cpp, which are to print margin,
border, padding, available sizes, and other computed sizes in ReflowInput. The
information can be replaced by adding local printf or via `rr` if there are
debug needs.
Note: `ReflowInput::DisplayInitFrameTypeEnter` and
`ReflowInput::DisplayInitFrameTypeExit` have been removed in
https://hg.mozilla.org/mozilla-central/rev/429a4d022ade
Differential Revision: https://phabricator.services.mozilla.com/D206314
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
The removed reftsts test basically the opposite, and are sufficiently
covered by the WPTs that we start passing, so just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D204797
The old code used to apply ShrinkWrap flag to both the inner table and the
caption if the table wrapper is a stretched grid item. However, per analysis in
bug 1350037 comment 4, when we reflow table captions, we'd like it *not* to
shrink-wrap, but to stretch its inline-size to at least as wide as the inner
table frame [1].
This patch moves the logic that computes whether a table is a stretched grid
item from `ReflowInput` to `nsTableWrapperFrame`, and apply the `ShrinkWrap`
flag to inner table if needed.
[1] https://searchfox.org/mozilla-central/rev/54d6d78c3b33c92fd9eef9c0555a153bf8e4f2b4/layout/tables/nsTableWrapperFrame.cpp#760-763
Differential Revision: https://phabricator.services.mozilla.com/D196705
We can pass `ComputeSizeFlag::ShrinkWrap` flag when creating the `ReflowInput`
for a flex item. It is maybe more verbose, but less of the magic flex logic
hidden in `ReflowInput`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D196258
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
