You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SVG fixtures are loaded more leniently in tests than in the webview #76
The SVG fixtures are parsed one way by the tests and another way by the code they stand in for.
Tests: packages/extension/test/svg-theme.test.ts:39 does document.body.innerHTML = text.slice(start) — the HTML parser, which is deliberately forgiving and never reports an error.
The webview: packages/extension/src/webview/preview.ts:330 does new DOMParser().parseFromString(svgText, 'image/svg+xml') — the XML parser, which surfaces a <parsererror> and, per installSvg, causes the diagram not to be shown at all.
So a fixture can be malformed in a way the suite accepts and the real path rejects. The tests then assert against a DOM the extension would never have built.
It has already happened
While adding template-with-cluster-legacy.svg I wrote a header comment containing --rm. A double hyphen is not legal inside an XML comment, so the document is not well-formed. The full suite stayed green. It was caught only by running an external XML parser over the file by hand:
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 30, column 17
Had that shipped, svg-theme.test.ts would have gone on passing while the webview refused the document outright — the tests asserting confidently about a diagram the extension could not display.
Both fixtures are well-formed today; the gap that let it through is not closed.
Suggested shape
Make the fixtures pass through the same gate the webview uses, so leniency cannot hide a malformed one. Roughly:
Parse each fixture with DOMParser / image/svg+xml in install() and fail on parsererror, rather than assigning innerHTML; or
Keep innerHTML for the DOM the assertions need, and add a separate test that every file in test/fixtures/svg/ is well-formed XML.
The first is closer to what the webview does and needs no second list of fixtures to maintain. Worth checking that happy-dom's DOMParser reports parsererror the way a browser does before relying on it — if it does not, the second option is the honest one.
Acceptance
A malformed fixture fails the suite.
Reintroducing the exact --rm-in-an-XML-comment defect is a red test, not a green one.
Activity