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
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
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
In the next part, I'm going to use ComputeSizeFlags as the arguments in
some ReflowInput's methods. Because nsIFrame.h includes ReflowInput.h,
to solve the circular dependency, ComputeSizeFlags needs to be moved to
somewhere else.
Also, revise the document for ComputeSizeFlag. The rest of the patch is
just dropping `nsIFrame::` and adding `mozilla::` as needed.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89542
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
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
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
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
