This patch is just flipping some logic in a way that should produce the same
outcome, so it shouldn't affect behavior.
MozReview-Commit-ID: LM4HbJD3D9w
This patch shouldn't change our layout order or paint order for flex items
(though it will change our behavior for the better when an abspos child is
present, as discussed in bug 1345873).
This patch *will* change the tab-index behavior of flex items. Previously, the
default tab order would match the visual order (i.e. it would respect "order"),
because it depends on the frame tree, and we sorted the frame tree by
"order". Now, the tab-index will come from the DOM order (the unmodified frame
tree), as the spec requires.
MozReview-Commit-ID: 9OsqQX1sEn3
This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_SET_INCOMPLETE\(\*([a-zA-Z0-9.*]*)\)" "\1->SetIncomplete()"
rename "NS_FRAME_SET_INCOMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.SetIncomplete()"
MozReview-Commit-ID: GOd4y2N6dcz
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_IS_COMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.IsComplete()"
MozReview-Commit-ID: GOd4y2N6dcz
For some stretched items, we override the computed height of the input for
measuring reflows, which may change the ascent and height result.
Just use that as a key for the reflow result cache too.
MozReview-Commit-ID: 9NyObfVucnC
This patch is to prevent any new callers of this API, since we can now rely on
the new frame state bit (NS_STATE_FLEX_IS_LEGACY_WEBKIT_BOX) to test for this.
MozReview-Commit-ID: BONaqPC30Cn
Note that at the callsites in nsCSSFrameConstructor.cpp, we have to also check
the frame type (since the frame state bit is in a range of bits whose meaning
differs depending on frame type). The first change in this patch is the
addition of a convenience fucntion that checks both the frame type as well as
the frame state bit.
MozReview-Commit-ID: DEOThTX5NAO
Right now, there's only one flag in this new class (with no usages until a
later patch). This flag suppresses a hack, which otherwise makes us
transparently reverse the child list & flex axes in some circumstances, to
prevent bottom-to-top child ordering. (We don't want that hack when we're
dealing with individual abspos children, since it only makes things more
complicated.)
MozReview-Commit-ID: HYUf0vjlfiJ
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
This patch makes the following specific changes:
(1) Adds an early-return to both versions of the IsOrderLEQ function, to treat placeholder children as LEQ everything (including each other). This will tend to sort them to the beginning of the child list, which is unimportant but fine. More importantly, though: this means our "order"-sorting code won't reorder placeholders *with respect to each other* (since our sort algorithm is stable). So their painting order won't be affected by the "order" property, which is required by the spec.
(2) Drops some nsPlaceholderFrame::GetRealFrameFor() calls -- they're unnecessary, since any placeholder frames will have prompted us to return earlier.
One caveat to (2): this patch does leave a few "nsPlaceholderFrame::GetRealFrameFor()" calls in place, *for the moment*. These remaining calls are for handling placeholders that are wrapped, i.e. inside of anonymous flex items. These calls are still needed to avoid assertion-failures (i.e. to get a consistent ordering) at this point, but they'll be removed in a later patch in this same bug, when we stop wrapping placeholders in anonymous flex items.
MozReview-Commit-ID: 1R6NW30Kxgv
Right now, there's only one flag in this new class (with no usages until a
later patch). This flag suppresses a hack, which otherwise makes us
transparently reverse the child list & flex axes in some circumstances, to
prevent bottom-to-top child ordering. (We don't want that hack when we're
dealing with individual abspos children, since it only makes things more
complicated.)
MozReview-Commit-ID: HYUf0vjlfiJ
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
This patch makes the following specific changes:
(1) Adds an early-return to both versions of the IsOrderLEQ function, to treat placeholder children as LEQ everything (including each other). This will tend to sort them to the beginning of the child list, which is unimportant but fine. More importantly, though: this means our "order"-sorting code won't reorder placeholders *with respect to each other* (since our sort algorithm is stable). So their painting order won't be affected by the "order" property, which is required by the spec.
(2) Drops some nsPlaceholderFrame::GetRealFrameFor() calls -- they're unnecessary, since any placeholder frames will have prompted us to return earlier.
One caveat to (2): this patch does leave a few "nsPlaceholderFrame::GetRealFrameFor()" calls in place, *for the moment*. These remaining calls are for handling placeholders that are wrapped, i.e. inside of anonymous flex items. These calls are still needed to avoid assertion-failures (i.e. to get a consistent ordering) at this point, but they'll be removed in a later patch in this same bug, when we stop wrapping placeholders in anonymous flex items.
MozReview-Commit-ID: 1R6NW30Kxgv
This shouldn't change our behavior right now, but it will make a difference
after bug 1269045 -- when that bug lands, we'll have nsPlaceholderFrames (which
are not flex items) in the child-frame list, which means we can't depend on its
first entry being a flex item anymore.
MozReview-Commit-ID: KRXYaK8R8bc
This removes a (very minor) optimization. The optimization was simply that we
avoided storing this nscoord value, if we could tell that we weren't ever going
to need it. Now it's becoming a bit more complicated to prove that we'll never
need it, so we might as well just store it unconditionally.
MozReview-Commit-ID: 94FFc9SO516
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
