After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Depends on D125610
Differential Revision: https://phabricator.services.mozilla.com/D125611
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
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
The inconsistent usage of block size and aspect ratio in ComputeSize() and
ComputeISizeValue() cause this assertion.
We use StyleSizeOverrides when measuring the content block sizes of flex
items, and the expected computed value of block size is auto.
And so in ComputeISizeValue(), we should use any field in StyleSizeOverrides
that having an override rather than fetching it from the style system.
Differential Revision: https://phabricator.services.mozilla.com/D111031
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
Include the scaling factor in the SizeConstraints struct so that widgets can
correctly constrain their width and height when the widget's scaling factor
differs from the nsPresContext.
Differential Revision: https://phabricator.services.mozilla.com/D109265
While nsInlineFrame and nsFirstLetterFrame are going to continue sharing the same code, nsRubyFrame will use the refactored version to compute its intrinsic sizes.
This way we can also eliminate the need for checking the intrinsic type inside the function.
This patch shouldn't change behavior. It's just a refactoring of existing code.
Differential Revision: https://phabricator.services.mozilla.com/D109227
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
This is a preparation patch for Part 2 -- We need a way to ignore
aspect-ratio when measuring a flex item's content block-size, because we
don't want the stretched inline-size transferring through aspect-ratio
to set block-size.
This patch hasn't changed the behavior yet. Part 2 is going to utilize
mAspectRatio.
Differential Revision: https://phabricator.services.mozilla.com/D106383
`UseAutoISize` flag is buggy when used on table flex items because it
never propagates to inner table frame.
Luckily, we can fix it by replacing the flag with StyleSizeOverrides
emplacing an 'auto' mStyleISize, because when computing the size, the
size overrides already propagates from table wrapper to inner table via
the following path:
`nsTableWrapperFrame::ComputeSize()` [1] ->
`nsTableWrapperFrame::ComputeAutoSize()` ->
`nsTableWrapperFrame::InnerTableShrinkWrapISize()` ->
`nsTableFrame::ComputeSize()`.
Part 3 is going to propagate the size overrides to inner table in
`nsTableWrapperFrame::CreateReflowInputForInnerTable()` during reflow.
This patch fixes the content size suggestion for table flex items.
Combining this patch with Part 3, we can fix those reftests in Part 4.
[1] In this patch, the table wrapper is still using nsContainerFrame's
ComputeSize(), but Part 3 is going to override it.
Differential Revision: https://phabricator.services.mozilla.com/D103438
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
After Part 5 & Part 6, we don't need to override flex item's flex-basis
proprety or preferred main size in ComputeSize() and
ComputeSizeWithIntrinsicDimensions(), we can change the two style sizes
to references, and give both of them to shorter names.
Differential Revision: https://phabricator.services.mozilla.com/D102475
FlexItem::StyleCrossSize() hasn't been used in this patch, but it will
be used in a later patch that revises size overrides in flex item's
final reflow.
Differential Revision: https://phabricator.services.mozilla.com/D101796
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
If aspect-ratio is '<ratio>', now the aspect-ratio works with box sizing
dimensions for replaced elements.
Also, ComputeRatioDependentSize() already considers writing-mode so we don't
need the conversion like logicalRatio in the old code.
For those calculations for intrinsic size contribution, we will fix them
in a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D100175
Making them non-overflow containers is valid but then we can't just
append them to mFrames since that'll put them on the last line which
may result in some lines in-between the pulled child and its
continuation. That violates the invariant that in-flow continuations
in the same parent must be on consecutive lines (unless they are
overflow containers in which case they need to be on the
[Excess]OverflowContainers lists).
(The crash happens because if we push the lines in-between the two
continuations to the OverflowLines, then we won't find the 2nd
continuation on the first line of OverflowLines.)
(Note also that this change triggers the assertion in
DrainExcessOverflowContainersList, and depends on bug 1680406
to fix that and merge the lists.)
Differential Revision: https://phabricator.services.mozilla.com/D99560
