Bug 1383323: Add a property_database.js testcase to verify that we reject radial-gradient() expressions that lack comma between shape and first color (iff stylo is enabled). r?xidorn
As noted in my code-comment here: Gecko's CSS parser incorrectly accepts this
CSS -- wherease Stylo correctly rejects it. Rather than trying to fix this in
Gecko, I'm just adding it in such a way that our expectation changes depending
on which CSS engine we're using. This lets us regression-test this in our
now-default stylo configuration, and still detect accidental/unexpected
behavior-changes in Gecko.
MozReview-Commit-ID: whLGIrh7TQ
--- a/layout/style/test/property_database.js
+++ b/layout/style/test/property_database.js
@@ -496,16 +496,31 @@ var basicShapeUnbalancedValues = [
"inset(1px",
"inset(1px 2px",
"inset(1px 2px 3px",
"inset(1px 2px 3px 4px",
"inset(1px 2px 3px 4px round 5px",
"inset(1px 2px 3px 4px round 5px / 6px",
];
+
+// Gradient values that are incorrectly accepted in Gecko, but are correctly
+// rejected with Servo's style-system backend (stylo):
+let gradientsNewlyRejectedInStylo = [
+ "radial-gradient(circle red, blue)",
+];
+if (SpecialPowers.DOMWindowUtils.isStyledByServo) {
+ invalidGradientAndElementValues.push(...gradientsNewlyRejectedInStylo);
+} else {
+ // NOTE: These are technically invalid, but Gecko's CSS parser thinks they're
+ // valid. So, if we're using Gecko's style system, we add them to the
+ // "valid" list, so we can at least detect if the behavior changes.
+ validGradientAndElementValues.push(...gradientsNewlyRejectedInStylo);
+}
+
if (IsCSSPropertyPrefEnabled("layout.css.prefixes.webkit")) {
// Extend gradient lists with valid/invalid webkit-prefixed expressions:
validGradientAndElementValues.push(
// 2008 GRADIENTS: -webkit-gradient()
// ----------------------------------
// linear w/ no color stops (valid) and a variety of position values:
"-webkit-gradient(linear, 1 2, 3 4)",
"-webkit-gradient(linear,1 2,3 4)", // (no extra space)