Also, rewrite CalculateAbsoluteSizeWithResolvedAutoBlockSize(). Move
all the aspect-ratio checks into this function, so make the caller simplier.
Differential Revision: https://phabricator.services.mozilla.com/D109568
This patch creates a new behavior for absolute positioned frames such
that if they have intrinsic size keywords (-moz-fit-content, min-content,
max-content) for their BSize and the margins are auto, instead of taking
as much space as possible, use the actual intrinsic BSize as the BSize.
Users can still use `auto` keyword to make it to fill the available
space.
This change is to align with the spec text for these intrinsic sizing
keywords at https://drafts.csswg.org/css-sizing/#valdef-width-min-content,
per the changes resolved on in https://github.com/w3c/csswg-drafts/issues/3973
This patch modifies the centering.html WPT, to expand the test
cases to test the centering functionalities for not only explicitly specified
height and width, but also the default size and width, in this case the
intrinsic sizing keywords.
Differential Revision: https://phabricator.services.mozilla.com/D106497
Based on the discussion in
https://github.com/w3c/csswg-drafts/issues/5721#issuecomment-781702159,
the default ratio-dependent axis is block axis (though the spec issue is
for replaced elements, but I think the behavior should be consistent).
So we should apply aspect-ratio not matter what the inline size is (e.g.
nscoord_MAX, auto or other values).
In the test case, the min-block-size is 1073741823, and its transferred
min-inline-size is also 1073741823, so we get a 1073741823 (i.e. nscoord_MAX)
preferred inline size (i.e. result.ISize(aWM) == NS_UNCONSTRAINEDSIZE).
However, we still have to apply aspect-ratio because the style of block-size is
auto, and so mFlags.mBSizeIsSetByAspectRatio should be set unconditionally here.
I still keep this assertion because it helps me catch this potential
issue. (Just reword it anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D107764
The mIsFlexContainerMeasuringBSize flag serves two purposes:
(1) Tell ReflowInput::ComputeMinMaxValues() to treat min-block-size and
max-block-size like the initial value.
We can just set both sizes after creating the ReflowInput, like this
patch does.
(2) Add `ComputeSizeFlag::UseAutoBSize` to mComputeSizeFlags.
Similar to the reasoning in Bug 1674302 Part 2
https://hg.mozilla.org/mozilla-central/rev/23aff0f21a1d, the
UseAutoBSize flag is buggy when used on table flex items because it
never propagates to inner table frame. We can fix it by providing an
'auto' mStyleBSize in StyleSizeOverrides.
This fixed table flex item's content block-size measurement. As
described in table-as-item-specified-height.html, the specified height
on <table> now won't count as another min-height anymore.
Differential Revision: https://phabricator.services.mozilla.com/D106157
The old code used to compute margins for table frame, and nuke it
afterwards. We can save time by moving the code that sets zero margins
into ComputeMargin() before looking into margin property.
Differential Revision: https://phabricator.services.mozilla.com/D104351
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
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
* Follow other flags' naming by putting "Is" at the beginning.
* Delete the accessor because we just access other flags directly.
Differential Revision: https://phabricator.services.mozilla.com/D102480
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
We have to set the flag, AspectRatioUsage::ToComputedISize if we
resolve the min-content/max-content/fit-content by aspect-ratio, so that
we can handle min-width:auto well.
Differential Revision: https://phabricator.services.mozilla.com/D99406
We may use the block size to compute the inline size if there is a
non-auto finite aspect-ratio and definite block size, so we need more
information on the block axis. Therefore, we have to pass LogicalSize
for containing block and boxing size adjustment.
Differential Revision: https://phabricator.services.mozilla.com/D99289
The issue is that nsTextControlFrame might have a different used padding
then the editing root block and thus the editing root's scrolled
content, etc, because its padding doesn't match the style.
This causes TextOverflow code to miscompute the content area size, which
is sadness and causes the overflow markers to go over the padding box.
The REFLOW_ROOT condition was introduced in bug 157846 and only
partially takes care of the issue. This fix supersedes it, so we can
remove it.
Differential Revision: https://phabricator.services.mozilla.com/D99838
We can use them to implement SetComputedWidth() and SetComputedHeight()
rather than the other way around.
The logic involving whether to call InitResizeFlags() for viewport frame
can be simplified. That is, we don't want to call InitResizeFlags() for
viewport frame in SetComputedISize().
Remove unused ComputedWidth() and ComputedHeight() that return
writable-references.
Differential Revision: https://phabricator.services.mozilla.com/D99500
I put the private member section at the end of ReflowInput's
declarations. In later patches, other members are going to live there
when they're converted to logical coordinates.
Remove unused AvailableWidth() and AvailableHeight() that return
writable-references.
I didn't port the comment section verbatim, but revise them according to
the best of my knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D99499
This doesn't hold with fractional scale values. Right now GTK truncates
the scale factor, Windows rounds, and non-native theme rounds as well.
With this native theme will propagate correctly the floating point
values.
I tried to not change behavior meaningfully in any of the other themes,
mostly to avoid risk. GTK and Windows can be trivially tweaked to
support fractional scale factors properly if we wanted to, but seems
better to not do that as part of this patch.
Depends on D98099
Differential Revision: https://phabricator.services.mozilla.com/D98100
I'd like to handle aspect-ratio in those code block, so it'd be better
to always handle unconstrained block-size on the writing mode of the current
block. Besides, we move it as a method of ReflowInput.
Differential Revision: https://phabricator.services.mozilla.com/D97515
