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
We store this new bit in nsIFrame instead of in ReflowInput to record a
change to padding (inspired by the mHasBSizeChange bit). That is because
we may construct a ReflowInput more than one time before reflowing the
frame. The first construction of ReflowInput (in
SizeComputationInput::InitOffsets) will update
nsIFrame::UsedPaddingProperty() using the latest style data, so
we *cannot* determine the padding change in any of the subsequent
construction of ReflowInput.
dynamic-change-inline-size-001.html is the scenario fixed by
bug 1307853. We've already passed this test without this patch.
dynamic-change-inline-size-002.html is equivalent to 001.html except
it's written with "box-sizing:content".
dynamic-change-inline-size-003.html is adapted from testcase 2 in bug
1729122 comment 4. Both tests pass after this patch.
Differential Revision: https://phabricator.services.mozilla.com/D126422
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126031
If so, `dependsOnCBBSize` will be set to true, and later in
`ReflowInput::InitResizeFlags()` we will add
`NS_FRAME_CONTAINS_RELATIVE_BSIZE` to the appropriate ancestor.
Sorted the #include statements in ReflowInput.cpp because I added
nsFlexContainerFrame.h.
Differential Revision: https://phabricator.services.mozilla.com/D123703
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
The issue is that combobox display may contain some non-Latin characters
that need extra block-size to display than the one line-height
calculate by using a Latin font spec in combobox control's style.
Before this patch, when a combobox control has unconstrained block-size,
we set combobox display's block-size to combobox control's one
line-height in Reflow(), which is intended to properly initialize
`BlockReflowInput::mMinLineHeight` since combobox display has
`line-height:-moz-block-height`. However, this simply prevents the
combobox display from choosing a larger block-size after the reflow. See
bug 1716212 comment 11 for an analysis.
This patch fixes the issue by carrying combox control's computed line
height to combobox display so that its computed block-size is still
unconstrained so that it can accommodate taller characters in the
display text.
After this patch, <select><option> containing non-Latin characters
should have the same block-size as <button>, and no characters should be
clipped. Modified test_unstyled_control_height.html to test this.
Differential Revision: https://phabricator.services.mozilla.com/D120877
This is an known issue for nscoord because we don't have a better way to
distinguish between the unresolved size and the resolved super large size.
Using NS_WARNING_ASSERTION is the current acceptable way.
Differential Revision: https://phabricator.services.mozilla.com/D119470
The helper is going to be used in a later part.
I don't add the physical version ComputedPhysicalBorder() deliberately
because I don't want to promote the usage of physical coordinate.
Differential Revision: https://phabricator.services.mozilla.com/D114544
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
