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
--HG--
extra : rebase_source : 185f5d6f5a3c8306761860c579eff10d931f3b35
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
--HG--
extra : rebase_source : aa8b11d3a756c9e7c521e6ffd70713af0174bd98
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
--HG--
extra : rebase_source : 7e4bf712d6ebd23efae5495e4e6c130cd1dba8cb
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
--HG--
extra : rebase_source : 95e86eec663b3ef2e7bb86214871fcd3ea86057c
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
--HG--
extra : rebase_source : 835a64e0f9cdaa375f8e57f55ffe5b011525cbeb
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
--HG--
extra : rebase_source : c600a80b96df3c937f2a56a5e0ed1825750234e0
(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
--HG--
extra : rebase_source : 4be8ac901e10de20747ed44b889d234646d4b2fd
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.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
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
Ting-Yu Lin
Daniel Holbert
Emilio Cobos Álvarez
Mats Palmgren
Mats Palmgren
Brad Werth
Phil Ringnalda
Julian Descottes
Wes Kocher
Xidorn Quan
Nicholas Nethercote
Emilio Cobos Álvarez