Instead, sort stuff using CSSOrderAwareFrameIterator. The current
sorting is broken in presence of dynamic insertions, consider the
following <Child(order)> combination in the DOM:
<A(1000)> <B(0)>
That'd look like:
<B(0)> <A(1000)>
On the frame tree. However when appending a child before B so that the
DOM looks like:
<A(1000)> <C(0)> <B(0)>
The frame constructor will properly insert after A, and the reordering,
which is stable, will end up with:
<B(0)> <C(0)> <A(1000)>
Which is the wrong frame tree order.
We only use -moz-box-ordinal-group in regular sprocket layout, so just
handle it there rather than everywhere. Similarly, we only rely on it
for in-flow stuff, so remove the test for that added in bug 877890 (flex
changed behavior afterwards, interestingly enough).
Differential Revision: https://phabricator.services.mozilla.com/D94790
nsTArray::StableSort() requires the Comparator to be a class/struct with
Equals() and LessThan() members, or a tri-state function like strcmp.
This patch adapts the original comparators to tri-state functions to
fulfill this contract.
Using StableSort() can also avoid the array bound checking in the array
iterator as described in bug 1147091 comment 8.
Change the include to <limits> because std::stable_sort is removed but
we still use std::numeric_limits.
Differential Revision: https://phabricator.services.mozilla.com/D82118
This patch just adds an optional codepath that isn't taken yet, so it shouldn't
affect our behavior. (The next patch in the series will make use of this new
codepath.)
Note: the large code-comment that this patch adds is taken mostly-verbatim from
some nsFlexContainerFrame.cpp code. (The original copy will be removed by the
next patch in this series, when we switch to take advantage of this new
mechanism.)
MozReview-Commit-ID: 9pkJ346rrXg
Emilio Cobos Álvarez