Frozen flex items have already been clamped to their min/max sizes, so their
size-change isn't a "how much we want to flex" measurement, and it's not useful
for determining whether the rest of the line is shrinking.
This patch is just adding a `if (!item->IsFrozen())` check around some code,
and reindenting that code, and adjusting a few comments.
This change is necessary to avoid failing the "GrowthState" assertions,
because (for example) a flex item that's clamped to a small max-width
could fool us into thinking we're in a "shrinking" state (since its final
size is smaller than its base size), even though really we're
in a "growth" state and the item was simply clamped. We avoid this
problem by skipping (potentially-clamped) frozen items when determining
the line's GrowthState.
Depends on D8922
Differential Revision: https://phabricator.services.mozilla.com/D9018
--HG--
extra : moz-landing-system : lando
We'd like to be able to record the "desired" (pre-clamped) delta size from
tentatively flexing for these items. That size would be computed during a loop
of the flex layout algorithm -- but we can't do that if we freeze them before
we start flexing. So let's bypass this early freeze so they get a chance to
compute this tentative size, even though they can never have it.
Differential Revision: https://phabricator.services.mozilla.com/D8922
--HG--
extra : moz-landing-system : lando
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
If we're waiting on an interrupt, then our child items haven't been totally
reflowed and our measures would be bogus.
This will probably regress performance in the cases bug 1209697 fixed, so we
should probably add an interrupt check somewhere in nsFlexContainerFrame to
avoid keeping reflowing flex containers indefinitely.
We could probably just bail out from our reflow if any kid reflow was
interrupted.
Filed bug 1495532 to consider that.
Differential Revision: https://phabricator.services.mozilla.com/D7288
--HG--
extra : moz-landing-system : lando
A flex item's available inline size would be relevant (i.e. would have an
impact on layout) if we were fragmenting the flex item in its inline direction
(e.g. if it were an inline-level box, in an inline-layout context).
But we're not doing that, so its available isize doesn't make a difference. To
the extent that it's been useful at all in this flex-item-caching code up to
this point, we'll now be caching something more-specific (the item's *computed*
inline size) which should serve roughly the same purpose.
Depends on D6991
Differential Revision: https://phabricator.services.mozilla.com/D6992
--HG--
extra : moz-landing-system : lando
Right now, when a flex item's intrinsic size is invalidated, we clear cached
flex measurements on all of its sibling flex items (indirectly, by virtue of
invalidating the flex container's intrinsic sizes, which does the dirty work of
clearing the measurements).
This is excessive. We do need to clear the measurements on any flex item
whose intrinsic sizes are invalidated, but we don't need to clear them on other
flex items whose intrinsic sizes are still valid. So: this patch changes our
implementation accordingly.
This patch isn't expected to change behavior - it should just be an
optimization.
Differential Revision: https://phabricator.services.mozilla.com/D5917
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : 185f2409dcb2f9c5bd0a2466a8e2233d7db3250a
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
--HG--
extra : rebase_source : a7c87b03ac8240ba71efd2198ce1976d96c91f64
This patch does not change behavior; it just merges the implementations of
these two functions into a single common function.
MozReview-Commit-ID: BqsRt3p2NQT
--HG--
extra : rebase_source : e8792f2bed3fd0708ffb38b91cf15a78cb6fbd59
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
--HG--
extra : rebase_source : 17efe1e9f721324d6182db654e601727c791800b
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
--HG--
extra : rebase_source : 695a2341074b1c344a1c5831989b95a693e16970
-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
--HG--
extra : rebase_source : 81e62163bf41a5d5dd87abf5397e6e8c62ed4096
extra : source : 653a9fc279e2f6a6d066474a94a70d65ac703d6b
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
--HG--
extra : rebase_source : e8e92bbaadb5b8e636bd1dda79cb0041ce36a2ea
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
--HG--
extra : rebase_source : 4697e6c23ea743e6b928b091c9dfc9ca1ce4c403
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
--HG--
extra : rebase_source : 92d20c8b607d9526c19f387258248388d1c89d85
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
--HG--
extra : rebase_source : 345e95978a8abd3ed3ab5b8acabbc6f163785f63
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
--HG--
extra : rebase_source : b25e8bfd7425f76b9784df0bd60fc454d4089347
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
--HG--
extra : rebase_source : 74caa7a1d06a2a9c5113d4e3cfabaa1d0e9ec1ab
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
--HG--
rename : layout/reftests/flexbox/flexbox-resizeviewport-1-helper.html => layout/reftests/flexbox/flexbox-resizeviewport-2-helper.html
rename : layout/reftests/flexbox/flexbox-resizeviewport-1-ref.xhtml => layout/reftests/flexbox/flexbox-resizeviewport-2-ref.xhtml
rename : layout/reftests/flexbox/flexbox-resizeviewport-1.xhtml => layout/reftests/flexbox/flexbox-resizeviewport-2.xhtml
extra : rebase_source : c6535e1cdcb1757a16cd02e0d485638827344c23
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
--HG--
extra : rebase_source : 856e90428468aac0d93854a0bc20e78c2dcb8c57
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
--HG--
extra : rebase_source : 60d7e52ed9a53f0c0d3ebf3103cbdab476606ddb
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
--HG--
extra : rebase_source : 96af106d739256a6871e75d0d34e9691cfbfb0c2
Daniel Holbert
Brad Werth
Manuel Rego Casasnovas
Emilio Cobos Álvarez
Zhang Junzhi
Mihir Iyer
Cameron McCormack
Narcis Beleuzu
Andreea Pavel
Andi-Bogdan Postelnicu
Morgan Rae Reschenberg
Sebastian Hengst
Tristan Bourvon
Brindusan Cristian
Chris Peterson