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
In nsFrame::ComputeSize and nsFrame::ComputeSizeWithIntrinsicDimensions, the
following expressions
isFlexItem && usingFlexBasisForISize
isFlexItem && !usingFlexBasisForISize
are sometimes compiled by recent gcc/clang in the opposite order, viz
[!]usingFlexBasisForISize && isFlexItem. In this case the transformation is
correct as can be seen by analysing code earlier in these functions.
Unfortunately this causes Valgrind/Memcheck to report a branch on undefined
data which, in this case, is a false positive.
A simple fix is simply to initialise usingFlexBasisForISize to false at its
declaration point.
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
