Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Bug 1674302 made table flex item to be able to grow or shrink towards
another size. However, for an inflexible table flex item, its
hypothetical main size is the final main size. We have to compute the
flex base size correctly when generating FlexItem.
With Part 1, it's easy to change nsTableWrapperFrame::ComputeSize() to
return the correct block-size.
Differential Revision: https://phabricator.services.mozilla.com/D106156
We already compute both the inner table frame and the caption frame's
block-sizes in InnerTableShrinkWrapSize() and CaptionShrinkWrapSize(),
respectively. Rather than throwing them away, popping them up to
ComputeAutoSize().
This is a preparation patch for Part 2, and it hasn't changed the
behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D106155
This is the main patch of this bug.
When a flex container provides size overrides for a table flex item,
there are two use cases.
(1) When resolving flex base size, we want to use `flex-basis` to
replace the preferred main size on the *inner table frame* directly.
This is how `height` works on a table element. That is, it sets the
height of the inner table frame, not the table wrapper. This patch
invents `mApplyOverridesVerbatim` flag to tell table wrapper frame don't
do any modification.
(2) When overriding main-size/cross-size for a table flex item, the size
is for *table wrapper frame*. To apply the size to inner table frame,
the table wrapper frame needs adjust the size by subtracting the area
occupied by caption, border, and padding (depending on the box-sizing).
This patch fixes the flex base resolution, and implements the logic for
(2).
We use nsLayoutUtils::GetStyleFrame() to dig into inner table's sizing
properties when resolving flex base size, so we can stop inheriting flex
properties to table wrapper frame in ua.css.
We also need to check style frame's StylePosition() in IsCrossSizeAuto()
so that non-'auto' sizes can prevent tables from being stretched in the
cross axis, just as happens with other flex items. Otherwise with this
patch, the table flex item with fixed height in
dom/flex/test/chrome/test_flex_item_rect.html will be wrongly stretched.
Differential Revision: https://phabricator.services.mozilla.com/D103437
This is a preparation patch for bug 1674302. We'll need border padding
to reduce the size for inner table size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D104643
If the table wrapper frame has a caption, several sizes that are used to
initialized inner table's ReflowInput needs to be reduced:
1. the available block-size,
2. containing block size,
3. StyleSizeOverrides (will be considered in bug 1674302).
This patch gives CreateReflowInputForInnerTable() an argument to pass
the space occupied by the caption in order to reduce the above sizes.
Note the old code doesn't reduce the constrained available block-size
when recreating ReflowInput for a table grid item, but this patch does.
Also, this patch goes ahead to recreate ReflowInput when the area
occupied by caption is non-empty, which may or may not affect the
containing block size for grid item. But for now, I keep it simple
because bug 16743202 is going to add logic that needs to recreate
ReflowInput when there is any size overrides. I tend not to
over-optimize the performance.
Differential Revision: https://phabricator.services.mozilla.com/D104642
Grid container stores the containing block size on a table wrapper grid
item in GridItemCBSizeProperty(), but the size is also passed as a
parameter when creating table wrapper's ReflowInput, and is stored in
ReflowInput::mContainingBlockSize. We can use mContainingBlockSize
directly instead of GridItemCBSizeProperty().
The test 002.html is inspired from the testcases in bug 1527734.
003.html and 004.html are inspired from the testcase in bug 1521088.
004.html is 003.html with 'width:500px' added to <table>, which we still
fail with this patch.
Differential Revision: https://phabricator.services.mozilla.com/D104144
When creating a ReflowInput for inner table frame in
CreateReflowInputForInnerTable(), we pass the customize border & padding
if the table frame is border-collapsed.
Similarly, when creating a SizeComputationInput for inner table frame,
we should be able to pass border & padding rather than having a
specialized logic in SizeComputationInput::InitOffsets(). This patch
makes this a reality.
Differential Revision: https://phabricator.services.mozilla.com/D104350
If the table wrapper frame has a caption, we don't need to compute the
flags twice, because the flag can be determined solely by table wrapper
frame's properties.
Differential Revision: https://phabricator.services.mozilla.com/D104349
Bug 1688690 has ensured inner table's computed margins are all zero.
Here, the only caller is asking the margin of the inner table, which is
always 0. Hence this patch.
Differential Revision: https://phabricator.services.mozilla.com/D104348
Split OuterBeginReflowChild() so that we don't need to branch logic for
caption and inner table.
Rename the methods because OuterBeginReflowChild() only creates the
ReflowInput, and has nothing to do with actual reflow. We could give
both methods the same name like `CreateChildReflowInput` and rely on
function overloading to call the correct method depending on the frame
type, but I prefer clearer method names.
Differential Revision: https://phabricator.services.mozilla.com/D104106
The purpose of InitChildReflowInput() is to provide customized border,
padding, and containing block size for the *inner table frame*, not for
the caption frame. So the caption frame's ReflowInput doesn't need to be
initialized in a separate step.
Differential Revision: https://phabricator.services.mozilla.com/D103436
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
It's straightforward to determine which writing mode is required to pass
to ComputedLogicalMargin() by looking at any subsequent method called on
the margin.
For example, if we see
```
ComputedLogicalMargin().BStartEnd(wm);
```
the writing mode needed to pass to `ComputedLogicalMargin()` is `wm`.
Differential Revision: https://phabricator.services.mozilla.com/D95661
Similar to the optional aContainingBlockSize parameter, both border and
padding should use logical coordinates in ReflowInput::mFrame's writing
mode.
Table frames that need to override border and padding can be simplified a bit.
However, DR_init_constraints_cookie and DR_init_offsets_cookie become more
complex, but they're only for debugging. I'm not planning to update their
internal APIs.
Differential Revision: https://phabricator.services.mozilla.com/D95369
Both are aliases to IntrinsicISizeType::MinISize and
IntrinsicISizeType::PrefISize.
Remove MOZ_ASSERT in nsLayoutUtils::IntrinsicForAxis and
nsContainerFrame::DoInlineIntrinsicISize since IntrinsicISizeType is a
enum class nowadays, which cannot have other values.
I've compiled this patch with DEBUG_INTRINSIC_WIDTH defined in
nsLayoutUtils.cpp, and fixed aWM undefined in
nsLayoutUtils::MinSizeContributionForAxis().
Differential Revision: https://phabricator.services.mozilla.com/D94618
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
This patch does:
1. Rename the original ComputeSizeFlags to ComputeSizeFlag (dropping the
"s"), and make it an enum class.
2. Make ComputeSizeFlags an EnumSet.
3. Adapt the users to use EnumSet's APIs.
The `Default` enum value in ComputeSizeFlag is not needed. It equals to an
empty ComputeSizeFlags.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89541
In order to apply Automatic content-based minimum sizes, we have to know
the content size on the block axis. We cannot get the content size until
we finish the reflow of the child frames. So we have to keep a flag
which indicates the size of the ratio-dependent axis is overrideen by
aspect-ratio in ReflowInput.
We will set the correct return value in the next patch, For now, we
always return AspectRatioUsage::None.
Differential Revision: https://phabricator.services.mozilla.com/D79335
This provides stronger typing and removes a bunch of subtle constants matching.
Differential Revision: https://phabricator.services.mozilla.com/D61058
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
