This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
This patch:
- adds fails-if annotations for all the reftests that were consistently failing
with layers-free turned on.
- removes fails-if or reduces the range on fuzzy-if annotations for all
the reftests that were producing UNEXPECTED-PASS results with
layers-free turned on.
- adds skip-if, random-if, or fuzzy-if annotations to the reftests that
were intermittently failing due to timeout, obvious incorrectness, or
slight pixel differences, respectively.
MozReview-Commit-ID: A0Aknn6rnjj
--HG--
extra : rebase_source : 420d9cf43f23a5d654fa36eec69138937d13c173
Unknown WR cset (WR was broken on LLVMpipe for a big range of changesets, and this
happened somewhere in that range, so it wasn't easy to bisect).
MozReview-Commit-ID: Id5kOdgpK9f
Previously, when these properties changed, we'd only send change hints to
recompute overflow areas & trigger DLBI. If the outline was always outside of
the element's border box, this old strategy was generally OK, because the
outline tweak would cause a change to the overflow areas' size, and that would
invalidate the changed area via DLBI & trigger a repaint.
However, for outlines that are *inside* of the element (via negative
'outline-offset'), these change hints were not sufficient, because tweaks to
the outline width & offset will NOT affect the size of the element's overflow
areas and will not trigger any DLBI invalidation.
So in order to correctly handle these changes, we really need to request a
repaint of the affected element, since some piece of the element may need to be
repainted even if it's not changing in size.
MozReview-Commit-ID: J4KGUHrJ09U
--HG--
extra : rebase_source : 677950d5aebdf7e90120b8fe7bb937344da42d7d
This patch was generated using a script and failure logs from a try push, so
whitespace formatting may not be the same as a human would do. The intent is to
fix many of these failures before merging back to m-c.
MozReview-Commit-ID: Etdx9LlWkLX
The outline-overflow-inline-block-* tests fail, as expected, with the
aOverflowOverride parameter to UnionBorderBoxes always changed to null.
Note that the outline-overflow-inline-block-* tests depend on the fix
for bug 709014.
At the same time, move the handling of outlines on inlines that contain
blocks earlier, so that we factor it into the stored frame property (and
thus have the stored frame property) and so that we include it
accurately in the overflow calculation.
At the same time, move the handling of outlines on inlines that contain
blocks earlier, so that we factor it into the stored frame property (and
thus have the stored frame property) and so that we include it
accurately in the overflow calculation.