[svgwg] Should the SVG matrix methods reject non-finite DOMMatrix2DInit values? (#1154)

karlcow has just created a new issue for https://github.com/w3c/svgwg:

== Should the SVG matrix methods reject non-finite DOMMatrix2DInit values? ==

Splitting this out of #326, where @longsonr asked it on 2020-06-13 and never got an answer:

> b) I pass {a: Infinity } and given that DOMMatrix2DInit takes unrestricted doubles unlike an SVGMatrix that should also result in a TypeError.

It has since produced a two-engine divergence.

```js
const svg = document.createElementNS("http://www.w3.org/2000/svg", "svg");

// Legal input: SameValueZero(NaN, NaN) is true, so validate-and-fixup step 1
// does not throw. Compare with {a: 1, m11: 5}, which does.
const init = { a: NaN, m11: NaN };

new DOMMatrix().multiply(init);
// Gecko and WebKit agree: a matrix carrying NaN. No exception.

const t = svg.createSVGTransform();
t.setMatrix(init);
// WebKit: t.matrix.a is NaN
// Gecko:  TypeError "Matrix setter is not a finite floating-point value"
```

Same dictionary, same validate-and-fixup, two different outcomes depending on whether you hand it to Geometry or to SVG. @longsonr's original `{a: Infinity}` behaves the same way: WebKit gives an `SVGTransform` whose matrix has `a === Infinity`, Gecko throws.

Implementing `SVGMatrix.multiply(DOMMatrix2DInit)` in WebKit (https://bugs.webkit.org/show_bug.cgi?id=318103) I hit the same case. Full shipping behaviour for `{a: NaN, m11: NaN}`:

| API | Gecko 155 | WebKit (patched) |
|---|---|---|
| `SVGMatrix.multiply` | TypeError "not a finite floating-point value" | `[NaN, NaN, 0, 1, 0, 0]` |
| `SVGTransform.setMatrix` | TypeError | accepts |
| `SVGSVGElement.createSVGTransformFromMatrix` | TypeError | accepts |
| **`DOMMatrix.multiply` (same engines)** | **`[NaN, NaN, 0, 1, 0, 0]`** | **`[NaN, NaN, 0, 1, 0, 0]`** |

Note the last row. Gecko's own `DOMMatrix.multiply` accepts NaN and returns it; the rejection is applied only at Gecko's SVG boundary (`IsFinite()` at dom/svg/SVGMatrix.cpp:96 and dom/svg/DOMSVGTransform.cpp:141). Blink does not implement these SVG methods with a dictionary at all, so it has no opinion yet.

As far as I can tell the spec text supports WebKit's behaviour:

- `DOMMatrix2DInit`'s members are `unrestricted double`, so NaN and Infinity are admissible.
- [Validate and fix-up (2D)](https://drafts.csswg.org/geometry-1/#matrix-validate-and-fixup) says nothing about finiteness. Its only rejection is the alias/element mismatch in step 1.
- Geometry 1 rejects non-finite values in exactly one place, the stringifier: **"If one or more of m11 element through m44 element are a non-finite value, then throw an InvalidStateError DOMException"**, with the note **"The CSS syntax cannot represent NaN or Infinity values."** That looks like a deliberate, narrowly-scoped decision; it is called out in the Changes section as **"The stringifier for DOMMatrix and DOMMatrixReadOnly now throws if there are non-finite values."**
- SVG 2's `setMatrix` algorithm defers wholly to Geometry: **"Let newMatrix be the result of `DOMMatrixReadOnly.fromMatrix(matrix)`, including the validate and fix-up steps for missing values. If that method throws an error, then re-throw that error and abort these steps."** No additional finiteness condition.

So the question is whether the SVG methods that take a matrix dictionary are supposed to be stricter than `DOMMatrix` itself. Three ways to resolve:

1. **No extra rule.** They behave exactly like `DOMMatrix`, and non-finite values propagate. Matches the current text and WebKit; Gecko would need to drop its `IsFinite()` gates. Non-finite values then reach `SVGTransform`'s value, so serialization of `transform` needs to be sane, worth checking given the stringifier carve-out above.
2. **Throw TypeError on non-finite.** Matches Gecko and @longsonr's (b). Needs explicit prose in SVG 2 for each method, since Geometry does not supply it. Also creates the oddity that `svgTransform.setMatrix(d)` throws where `new DOMMatrix().multiply(d)` does not, for identical input.
3. **Silently ignore.** What canvas does for `ctx.setTransform` and `Path2D.addPath`, and what Gecko happens to do for `CanvasPattern`. Probably wrong here: those have a "do nothing" outcome available, and the SVG DOM ones return a value.

I have no strong preference, though (1) is the least new normative text and the status quo for the wider platform. Mostly I would like the answer written down, because right now it is being decided implicitly by whoever writes the next implementation or the next test.

Whichever way it goes, WPT coverage should follow. Today the only non-finite dictionary coverage lives in `css/geometry/DOMMatrix2DInit-validate-fixup.html` and only exercises `ctx.setTransform` and `Path2D.addPath`; nothing in SVG has any.

The question applies identically to `SVGMatrix.multiply`, `SVGTransform.setMatrix`, `SVGSVGElement.createSVGTransformFromMatrix` and `SVGTransformList.createSVGTransformFromMatrix`. Context: #706 / #1143 widened `SVGMatrix.multiply` to take the dictionary.

Please view or discuss this issue at https://github.com/w3c/svgwg/issues/1154 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 28 July 2026 06:52:08 UTC