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
(Normally, the style-context parent will *be* the flex container's style
context, so this patch won't change behavior at all. But if a flex container
has a "display:table" child, then there's an extra style context in the
inheritance chain (due to how style inheritance works for nsTableWrapperFrame).
And we don't want that extra style context to mess up the ability of a flex
container's "align-items" property to actually align the flex items.)
MozReview-Commit-ID: GFyxhEwM68S
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
The main renaming was generated with the following python script:
```
import sys
import re
CAMEL_CASE_REGEX = re.compile(r"(^|_|-)([A-Z])([A-Z]+)")
DISPLAY_REGEX = re.compile(r"\bNS_STYLE_DISPLAY_([^M][A-Z_]+)\b")
def to_camel_case(ident):
return re.sub(CAMEL_CASE_REGEX,
lambda m: m.group(2) + m.group(3).lower(), ident)
def constant_to_enum(constant):
return "StyleDisplay::" + to_camel_case(constant) + ("_" if constant == "NONE" else "")
def process_line(line):
return re.sub(DISPLAY_REGEX,
lambda m: constant_to_enum(m.group(1)), line)
lines = []
with open(sys.argv[1], "r") as f:
for line in f:
lines.append(process_line(line))
with open(sys.argv[1], "w") as f:
for line in lines:
f.write(line)
```
And the following shell commands:
```
find . -name '*.cpp' -exec python display.py {} \;
find . -name '*.h' -exec python display.py {} \;
```
MozReview-Commit-ID: 91xYCbLC2Vf
