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
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
--HG--
extra : rebase_source : 2a27ea3bf9d3eabc437db398d24e374ce48ba677
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
--HG--
extra : rebase_source : 40f4e7dd6aacfb4f267d2f4d217fbf84befb5ebf
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
--HG--
extra : rebase_source : aff89907bfef41a8fa3ff076264a2b7a72c36e27
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
--HG--
extra : rebase_source : ff0ebd63c4a88017e8211a77049e79469b4e9858
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
--HG--
extra : rebase_source : d42a291c414c61906a82c2be2b5f1834aa24e4e3
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
--HG--
extra : rebase_source : 0c59e2a0adc8e060a687e5ffdf6246eb8068eef6
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
--HG--
extra : rebase_source : 9a89ce8782f735d7f4a8ad471606a2af5201ac83
This patch is effectively just resurrecting a function that was previously removed in https://hg.mozilla.org/mozilla-central/rev/173a4f49dfe3#l1.96 .
MozReview-Commit-ID: 4PXSOu4tzzU
--HG--
extra : rebase_source : 88deb29578bb6851b606f5088f6f18f3a65e8e3e
This patch is effectively just resurrecting a function that was previously removed in https://hg.mozilla.org/mozilla-central/rev/173a4f49dfe3#l1.96 .
MozReview-Commit-ID: 4PXSOu4tzzU
--HG--
extra : rebase_source : a8ada7319ea86ccb6178870510fdbb1dac6bd027
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
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
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
--HG--
extra : rebase_source : 2c3aa8d07ba23714501c9e26ad03625aeab36a7a
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
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
Daniel Holbert
Sebastian Hengst
Tristan Bourvon
Brad Werth
Brindusan Cristian
Emilio Cobos Álvarez
Chris Peterson
Phil Ringnalda
Ting-Yu Lin
Matt Woodrow
Alexis Beingessner