This patch accomodates for the unfortunate fact that elements with
"table-layout:fixed" have a max-content size of nscoord_MAX (infinity,
effectively), which turns out to be an easy source of integer overflow during
flex layout.
Before this patch, a flex container with "table-layout:fixed" in several flex
items could end up triggering integer-overflow & making the wrong judgement on
its arithmetic to determine...
- whether a given flex item will fit on an existing flex line.
- whether we've got positive free space and need to grow our items, or have
negative free space and need to shrink our items.
This patch makes two changes to fix this issue.
(1) This patch makes us use CheckedInt when summing up flex item hypothetical
sizes, which prevents integer overflow from flipping the sign of our line's
total length.
(2) This patch makes us *directly* track the space reserved for flex item
margin/border/padding within a flex line. Previously, we tracked this
implicitly as the difference between two other quantities that we stored;
but with the other changes in this patch, those two other quantities can
*both* trigger overflow and get clamped, which would make us lose track of
how much space to reserve for margin/border/padding. So now we simply
track that space-to-reserve directly.
MozReview-Commit-ID: 9izhOnlS4F1
Assuming we call MarkIntrinsicISizesDirty in the appropriate scenarios, this
patch shouldn't change behavior - it just caches these values so we don't
needlessly recalculate them.
MozReview-Commit-ID: 8QY4AZJXshy
This patch does not change behavior; it just merges the implementations of
these two functions into a single common function.
MozReview-Commit-ID: BqsRt3p2NQT
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
There's been a clarification to the spec text that this comment was worried about:
https://github.com/w3c/csswg-drafts/issues/2316
And with that clarification, this comment is no longer applicable.
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
-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
At this point in the series:
- AxisOrientationTracker::IsCrossAxisHorizontal() has zero callers, so it can
be deleted.
- AxisOrientationTracker::IsMainAxisHorizontal() only has two callers, and
both are inside its own class. So it's effectively become an implementation
detail of its class, and it can be made private. (I'm not entirely removing
it, because it does make its two callers more readable. The callers are
working with a physical-axis-dependent type, 'LayoutDeviceIntSize', which
comes from an API that isn't logical-axis-friendly, "GetMinimumWidgetSize",
so they're not easily logicalized. So: it's nice to keep
IsMainAxisHorizontal() around as an internal convenience method to tell us
whether to extract the width or height inside of these two specific
methods. But we don't want to introduce more callers, so let's leave it
around & make it private.)
MozReview-Commit-ID: 1iz1e52NmxV
This patch doesn't affect behavior. Each of these macros only had one caller
remaining, and this patch simply expands each of these macros at its sole
callsite.
Note that I'm using the "IsMainAxisHorizontal()" helper in *both* expansions
here, which makes the alternative variant "IsCrossAxisHorizontal()" unused as
of this patch. The next patch in this series will remove that now-unused
method, which will reduce the "Horizontal"-querying API surface here.
The documentation for the macros is still relevant to their still-existing
"_LOGICAL" variants (and those variants do still have callers), so I'm updating
the documentation to be about those variants.
MozReview-Commit-ID: 5i32VYXzo3r
This patch doesn't change behavior.
The GET_MAIN_COMPONENT macro (some of whose calls I'm removing here) makes a
call to IsMainAxisHorizontal() under the hood. So I want to get rid of calls
to this this macro, to get closer to killing that method.
In this code, we're interested in the flex item's min-size property in the flex
container's main axis. This patch makes us simply use MinISize/MinBSize (in
terms of the *flex container's* writing mode) to get the appropriate min-size
property. The call to IsRowOriented() (querying the flex container's
"flex-direction" property) tells us whether the inline or block axis is the
main axis.
This patch also does away with an unnecessary axis-specific 'overflow-{x/y}'
check, which we don't need to bother with, as noted in a new code-comment (due
to how the 'overflow' subproperties influence each other).
MozReview-Commit-ID: Kqyh69W5IQJ
This patch doesn't affect behavior. It does the following:
- Changes the AxisOrientationTracker "GetMainComponent/GetCrossComponent" APIs
to take a LogicalSize rather than a nsSize.
- Changes FlexItem::mIntrinsicRatio to be a LogicalSize rather than a nsSize.
- Simplifies the MainSizeFromAspectRatio() helper-function (in particular, it
removes a call to IsCrossAxisHorizontal(), which is an API I'm gradually
removing in this patch series.)
MozReview-Commit-ID: KXUmaUVPMZa
This patch doesn't change our behavior -- not in opt builds, at least. In debug
builds, this patch does change an assertion condition, to remove a usage of
IsCrossAxisHorizontal(). This means debug builds may proceed a bit further
when loading e.g. bug 1384266's testcase (which up until now was tripping this
assertion). Now that testcase fails a slighlty later assertion (which I'll
sort out on that bug).
The first hunk of this patch is just a simplification -- replacing a
complicated condition (IsRowOriented==IsOrthogonalTo) with a simpler
formulation of the same condition. I'm making that simplification in this
patch so that we're more clearly consistent about what condition we depend on
for baseline alignment. After this patch, that (simplified) condition matches
the condition that we assert inside of GetBaselineOffsetFromOuterCrossEdge().
Note: I'm adding two XXXdholbert comments in this patch, for outstanding issues
that I ran across which are out-of-scope for this patch series.
MozReview-Commit-ID: 5x5xqWWilQZ
This patch doesn't affect behavior.
It removes a helper-function that simply returned nsStylePosition::mWidth or
mHeight -- whichever was in the flex container's cross axis. This helper was
only used to answer the question "is the cross size 'auto'", at a single
callsite. So, this patch replaces the helper with a new helper that more
directly answers that question. The new helper's implementation uses logical
axes for its reasoning, too, whereas the removed one used physical axes (and in
particular, it relied on AxisOrientationTracker::IsCrossAxisHorizontal(), which
I'll be getting rid of later in this patch series).
MozReview-Commit-ID: EJ8MObTauZH
This patch mostly[1] doesn't affect behavior. It just changes some ReflowInput
width/height-setting logic to use ISize/BSize setters instead of width/height
setters.
To help with this, I'm also adding some more getters to answer the question "is
this flex item's {inline,block} axis the same as the flex container's
{main,cross} axis", for convenience/readability at callsites. (All of these
getters are simply giving a different view of the same underlying single bit of
information.)
[1] One way this patch *kind of* affects behavior: it generalizes the
conditions under which we set the NS_FRAME_CONTAINS_RELATIVE_BSIZE flag on a
flex item. But that doesn't actually have any user-visible effects right now,
because that flag's only purpose is to determine whether we should reflow, and
currently we always reflow all flex items. If/when that changes, though
(i.e. when we start reflowing flex items more selectively), this patch is
adding a reftest that may test this generalized behavior. (The reftest actually
trivially passes right now, due to unrelated bug 1441348.)
MozReview-Commit-ID: 4NEKLBAjowh
This patch doesn't affect behavior. It just replaces some (correct) physical-axis-dependent code with equivalent logical-axis-dependent code.
MozReview-Commit-ID: 27QJU2cFWh
This patch doesn't change behavior. It just makes us use logical axes/types instead of physical ones for this particular API and its caller.
MozReview-Commit-ID: Jt6SECGI9EU
This patch doesn't change behavior. It's purely to allow the next patch to be more surgical. Specifically, this patch:
- splits a subtract-and-clamp operation into two separate operations.
- splits one a comment into two.
...so that the next patch can swap out these variables for new ones, without
pushing these lines over 80 characters.
MozReview-Commit-ID: 4N5sI755CqF
This patch doesn't change behavior; it's simply a rename.
I'm also fixing one mistyped mention of this variable in a comment in
nsFlexContainerFrame.cpp. (The comment had "Reflow" rather than "Height" in
its mention of this variable-name.)
MozReview-Commit-ID: KRW7FCVSlto
In particlar, this patch:
- ...renames a bunch of 'auto'-BSize-measurement functions/variables from
"Height" to "BSize". (I thought about splitting this part out, but
typically the correctness of the renames was intrinsically tied to the logic
generalizations that I'm performing here, and vice versa, so it seemed
clearest to group it all together.)
- ...replaces some calls to IsMainAxisHorizontal() with the more general
"FlexItem::IsInlineAxisMainAxis()" API, for cases when we're reasoning about
whether a flex item's main-size is really just its (easier-to-resolve) ISize.
- ...replaces some calls to IsCrossAxisHorizontal() with either
IsColumnOriented() or FlexItem::IsInlineAxisCrossAxis() (depending on
whether we're reasoning about the flex container's cross-size vs. a flex
item's cross size).
This makes a bunch of tests start passing (including a "received" w3c
reftest/wpt-test), so this patch also removes some failure annotations.
MozReview-Commit-ID: 3uR1mOzvytX
This patch doesn't affect behavior -- it's just adding a new member-var &
accessor with no usages. The next patch in the series will add some usages.
MozReview-Commit-ID: NKBvKnb7Jw
This patch doesn't affect behavior. It simply reorders a member variable to be
near the beginning of the FlexItem class, so that the next patch in this series
can use that member-variable when initializing another member in the
constructor init list. (You're only allowed to use earlier member-vars like
this, since member-vars get initialized in order.)
MozReview-Commit-ID: 9v4Dr0Ir6i7
In modern flexbox and in "display:-webkit-box", children with
"visibility:collapse" currently generate "struts" which have 0 main-size but
nonzero cross-size.
But XUL/-moz-box treats these children differently -- it makes them 0-sized in
both axes. So we need to add a custom behavior to modern flexbox in order to
emulate that.
Specifically, this patch makes us:
- Ignore these children when computing the flex container's intrinsic sizes.
- Take a simpler codepath with 0-sized struts for collapsed elements when
laying out a -moz-box (rather than the typical 2-pass layout, with strut
cross-size being established in the 1st pass).
MozReview-Commit-ID: IpkADpFFBMx
To be clear, this is a "paving the way" patch. At this point in the patch
series, it's not yet possible for us to generate a nsFlexContainerFrame that
has display:-moz-box. (A later patch in this series will make that possible.)
This patch adds the mechanics to nsFlexContainerFrame instances so that they'll
label themselves appropriately (with NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX)
once it *does* become possible for -moz-box to spawn a nsFlexContainerFrame.
Moreover, this patch updates the state bit's documentation to reflect its new
potential-usage.
MozReview-Commit-ID: ElApieVoTLf
This patch isn't changing semantics of this bit at all - it just renames it to
a more general name. In other words, this patch does not change behavior.
MozReview-Commit-ID: 4wb13X4YinJ
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
We have a fair number of files that have a particular stale version of the MPL
boilerplate. (It was probably originally correct, and then the official
boilerplate changed, and the stale MPL boilerplate continued to propagate via
copypasting from neighboring files into newly-added files.)
This patch updates this stale MPL text (and *only* the MPL text) to the latest
version, which can be found at https://www.mozilla.org/en-US/MPL/headers/ and
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: 8WeBb8b0uRo
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
