This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
This brings us into alignment with the spec and makes us pass some web-platform
tests, along with the reftests that I've included for this bug.
MozReview-Commit-ID: KoKPi18svGE
This patch doesn't change behavior.
It simply makes us share code/data for two different cases that both ended up
producing mainAxisCoord->GetUnit() == eStyleUnit_Auto. Now, they'll *both* use
the same static nsStyleCoord to represent this "auto" value.
Originally, in one of these cases ("flex-basis:auto;[main-size-property]:auto),
we left the mainAxisCoord untouched. Now we'll point it at this dummy 'auto'
value. Either way we end up with mainAxisCoord->GetUnit() == eStyleUnit_Auto,
so the behavior doesn't change.
The next patch in this series will make further changes to one of these spots,
as noted in the "XXXdholbert" code-comment included here.
MozReview-Commit-ID: 5ClfbNHuKhO
This is needed only for CSS Grid since in other cases we're
only using IntrinsicISizeOffsets in the inline-axis and
the percentage basis is always indefinite for *intrinsic
sizing*. When calculating the intrinsic size of grid items
in the grid container's block axis however, we do have
a definite size for the grid area in the inline-axis and it
should be used per:
https://drafts.csswg.org/css-grid/#algo-overview
"2. Next, the track sizing algorithm resolves the sizes of
the grid rows, using the grid column sizes calculated in
the previous step."
(Percentage padding/margin for grid items is always resolved
against the grid area's inline-size nowadays.)
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
When we finish decoding an image frame, we need to trigger reflow for the
frame containing a float with shape-outside: <image>, and delay the firing
of the document's onload event until that reflow is complete.
This patch adds three test cases;
1) Animation on position:absolute element in a zero-height iframe
This animation should be throttled.
2) Animation on a non-zero width and hight position:absolute element but whose
parent has a zero height
This animation should NOT be throttled since the animation is visible
3) Animation on a zero-height position:absolute element whose parent also has
zero height.
This animation should be throttled since the animation is invisible
The first test fails without this fix and passes with the fix.
The second one passes regardless of the fix
The third one is marked as 'todo' since it doesn't pass with this fix.
MozReview-Commit-ID: 8pNUFQ71ivj
BACKGROUND:
Early in flex layout, we have to resolve the 'flex-basis' value to produce the
"flex base size" (basically, the flex-basis resolved to an absolute length).
This resolution happens in two "phases" (which both happen within
nsFlexContainer::GenerateFlexItemForChild()):
First phase: we try to resolve the flex-basis by creating a ReflowInput for the
flex item (which gets us some other things as well). Under the hood, we use
the flex-basis when resolving this ReflowInput's main-axis size. The code for
this lives in nsFrame::ComputeSize (and in
nsFrame::ComputeSizeWithIntrinsicDimensions, via some frame classes' overrides of
ComputeSize).
Second phase: If the first phase didn't get us a definite size, then that means
we have to do reflow to measure the content size & produce a resolved flex base
size, which we do via ResolveAutoFlexBasisAndMinSize().
NOTES ON THIS PATCH:
To add 'flex-basis:content' support to layout, this patch only needs to modify
the first phase discussed above. If it turns out we also have some second-phase
work to do (i.e. if we need to do reflow to resolve 'flex-basis:content'), this
patch causes that reflow to happen by simply making us use eStyleUnit_Auto in
the main axis's nsStyleCoord in the first phase. (And then, if that 'auto'
nsStyleCoord really does require reflow, then that first phase will end up
producing an unconstrained main-size in the flex item's ReflowInput, which will
automatically trigger the second phase.)
MozReview-Commit-ID: 2nH4Fh78C81
This patch should not affect behavior.
Logic-wise: the idea behind this patch is to behave as if the
'usingFlexBasisForHeight' variable were always false, which in turn lets us
remove an "if (!usingFlexBasisForHeight || ...)" check, because it trivially
passes when that bool is false.
Background on this special case & why we can remove it:
=======================================================
In the original flexbox implementation, we had some special-case code to be
sure we didn't end up swapping in e.g. "flex-basis:-moz-min-content" for
"height" in these ComputeSize functions, because that was a scenario that
previously would've been prevented at the parser level (height:-moz-min-content
is rejected for now), and hence may not have ended up being handled robustly.
However, nowadays it'll be handled just fine in these functions, and will
produce the same result as our special-case exception tries to achieve.
In particular, for a nsFrame that is a flex item in a flex container with a
vertical main axis (the scenario that these special cases are catching):
- If the (vertical) main axis is this nsFrame's inline axis (i.e. if this
nsFrame has a vertical writing-mode), then Stylo actually converts
enumerated flex-basis values like "-moz-min-content" to "auto" when
producing the computed values that layout sees. So it's not actually
possible for layout to see a computed "flex-basis" of -moz-min-content, in
that scenario.
- Otherwise, i.e. if the (vertical) main axis is this nsFrame's block axis,
then these ComputeSize functions will now end up getting an enumerated
"blockStyleCoord" (really pointing to flexBasis), but that'll still end up
being treated like 'auto'. This happens by virtue of ComputeSize's calls to
ComputeAutoSize (which initializes the tentative bsize value to
NS_UNCONSTRAINEDSIZE) and to nsLayoutUtils::IsAutoBSize (which returns
"true" for eStyleUnit_Enumerated values and then makes us leave the
ComputeAutoSize result unperturbed).
I don't have a strong preference about blending with white vs. just doing alpha
0.5, so I kept doing what we were doing, since Blink and WebKit also apply the
blending to the text background, and I'm not sure that's particularly desirable.
MozReview-Commit-ID: AwYtAgdlcxj
This patch doesn't affect behavior; it just adjusts a variable for clarity.
Really, this variable tracks which axis (inline vs. block) is the main axis (if
we're a flex item). So, this patch morphs the variable to more directly track
that.
The variable's old name 'usingFlexBasisForISize' was confusing, because even
when it was set to 'true', we might not *really* be using the flex-basis in
place of the ISize property. In particular: when we have 'flex-basis:auto', we
don't use 'flex-basis' in place of the ISize/BSize property -- rather, that
indicates that 'flex-basis' is *deferring* to the main-axis size property.
Hopefully the new name/type makes it clearer what we're actually tracking.
MozReview-Commit-ID: ITkb4zuEwgQ
This patch doesn't affect behavior - it's just refactoring / de-duplicating.
(The refactored function does include some new "legacy box" code, just for
completeness & to ensure that the included assertion passes. But beyond the
assertion, that new code isn't exercised right now -- this function's only
callsites are skipped if the NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX state-bit is
set on the container. Hence, this patch still doesn't affect behavior, even
though it's adding some new logic in the refactored-out function.)
MozReview-Commit-ID: G5aCzwTwkTa
The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
