In the an+b syntax, this continues to allow comments and spaces like so:
` an + b `. It does not allow `a n+b`, or `- an+b` or `+ an+b` (and the
same for the `an-b` form). Similarly, it does not allow `- b` or `+ b`.
Additionally, it *does* allow `+/*comment*/n+b` or `-/*comment*/n+b`,
but not `+ n+b` or `-n+b`. This is specced; in this one case we
parse two tokens but do not allow whitespace in between.
MozReview-Commit-ID: INzFGeMPeK7
--HG--
extra : rebase_source : ca5bcf4034759823f79b9a925dc72998d8f0218b
This won't be an issue until the 57 release but at that time, the
reftest extensions will only load if the extensions.legacy.enabled
preference is set to true and Cu.isInAutomation, which depends on
another preference, is true. Set the appropriate prefs here for reftests.
MozReview-Commit-ID: JUWCPTsuJU
--HG--
extra : rebase_source : 042a5696d1926e7ca434a7c4213395176a080549
This patch just moves the calculation of the pseudo type earlier in the method
so we can re-use it in the next patch in this series to get the style context
from the Servo backend for the case where we don't need to resolve style.
This patch also renames the local variable from 'type' to 'pseudoType' since
that seems less ambiguous.
MozReview-Commit-ID: 6pi2F1vZYHJ
--HG--
extra : rebase_source : 1b9c610edbe4f07000b6cc2087f45dd04792228b
This catches a common problem where somebody adds a fuzzy annotation on
a test to work around some minor differences. Later the differences go
away, but since the test harness doesn't catch that, nobody is the
wiser. Subsequently a "real" regression can reintroduce differences
which are hidden by the stale fuzzy annotations.
With this patch, if the annotations are set up properly, the test
harness will flag tests as "UNEXPECTED-PASS" when the differences go
away. This will require the patch author to reduce the allowed fuzziness
parameters, and will make it easier to catch subsequent regressions.
MozReview-Commit-ID: B3rGPFLXkCu
This patch extends the "fuzzy" and "fuzzy-if" annotations so that they
accept a range of fuzziness values, much like the "asserts" and
"asserts-if" annotations. If the test produces differences that are
within the specified range, the test is considered as passing. Any
differences outside the ranges are considered failures. If the test is
marked as a "!=" test, then the opposite is true.
If the range given to "fuzzy" or "fuzzy-if" is a single value, it is
interpreted as being a range from zero to the specified value. This is
in contrast to "asserts" and "asserts-if" which match exactly the value
specified. The reason for this is mostly for backwards compatibility
with existing reftest annotation semantics.
MozReview-Commit-ID: 6qUU6FQ5mYP