Ensure void elements have closing slash in mermaid svg

[bollwyvl]

References

• starts Mermaid.js state diagrams do not always render in Windows #15660

Code changes

• transform <br> tags into closed <br/> when generating the img tag containing mermaid SVG

  • the regular expression will actually find all void elements, and preserves attributes

• test
  • add a test/notebook with examples of all (but one) of the upstream documentation examples
  • add screenshots

User-facing changes

• users will be able to use expressive more typographic features in mermaid diagrams

Security/Compatibility considerations

• some implementations (e.g. GitHub) will not even parse diagrams with any void elements (or probably any fancy HTML) except hr and br
  • currently, in this PR, as in the mermaid playground, one can do really interesting/outrageous things, for example:
    • the style="border-color: red" attribute can be used on an hr to change its color
    • <input type="checkbox" /> and radio can be used to do weird things
  • in the playground, these are actually clickable, etc. but sadly not feasible with the (otherwise robust and portable) <img/> approach
    • though text labels may contain further img tags
• no implementation render <script> tags
• onclick="javascript:alert('pwnd')" attributes do appear to pass through on the playground, and in 4.1.0b1 if a user goes through right-click, open in new tab and then interacts with the diagram

Backwards-incompatible changes

• if we decide to do more aggressive sanitizing, this could break some diagrams/examples in the wild

[jupyterlab-probot]

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

[krassowski]

Upstream issue: mermaid-js/mermaid#1766

What effect would the flowchart.htmlLabels=false suggested by mermaid team have on compatibility? Can we use it instead of manual HTML substitution?

[bollwyvl]

Yeah, there's that one (not sure how breaking). I need to take a look at various other control mechanisms. There's also a sandbox mode, which is probably worth investigating, though it does target an iframe with html srcdoc instead of SVG, so does more weird stuff to entities in foreignobjects. Ending up with an img tag is still the most portable output.

[bollwyvl]

htmlLabels=false

This does not solve the problem for \n in node labels.

sandbox

This resulted in strictly worse results e.g. >br< as these are "magic" entities, not defined in the SVG spec.

The <iframe srcdoc> approach is very attractive, as, for example, HTML (and therefore markdown) images can do icky things like:

This is totally valid markdown:

<img src="/api/shutdown" alt="shutdown"/>

And pretty much all frontends will render it, including (at least in preview) GitHub

This is totally valid markdown:

But marked communicates over strings, and filters out iframes... we probably don't want to change that posture, today, as they can very much be used for deceptive things, not just their "white hat" security techniques).

[krassowski]

But marked communicates over strings, and filters out iframes... we probably don't want to change that posture, today, as they can very much be used for deceptive things, not just their "white hat" security techniques).

Could we use the same splicing approach as we do with MathJax? See:

jupyterlab/packages/rendermime/src/renderers.ts

Lines 323 to 330 in e38e0b8

	// Separate math from normal markdown text.
	const parts = removeMath(source);
	// Convert the markdown to HTML.
	html = await markdownParser.render(parts['text']);
	// Replace math.
	html = replaceMath(html, parts['math']);

[krassowski]

Kicking this PR to check if the labeller for mermaid now works (#15717), also FYI once you merge/rebase the tests for mermaid should now run on CI.

[bollwyvl]

Thanks. Alas, it might be a tick before I can get back to this...

[krassowski]

This looks amiss? In general I am not a fan of that many snapshots but I am ok with these being here as long as they are isolated to the diagrams alone (no other UI).

[bollwyvl]

Of all the things a screenshot is good at, diagram renders right seems like a legit use case vs all the "whole screen" shots that are sensitive to individual pixel skew.

At any rate, these are now as isolated as they can be... the "screenshot element" function doesn't handle bigger-than-viewport stuff very well, and there are two examples diagrams that are larger than the viewport.

[krassowski]

I pushed a fix for this using workaround from microsoft/playwright#13486 (an upstream fix is apparently not planned).

[bollwyvl]

Thanks for the fix! Pretty weird its a non-priority upstream, as this hardly seems to that unique. As commented on the new file, perhaps this belongs someplace more prominent/easier to find?

[krassowski]

I would love to see this unit tested. For example input '<br/>' (which I understand we do not expect from the current version of marked but I guess user or future versions could introduce it) results in '<br / >' which strictly speaking is invalid XHTML. Basically:

new DOMParser().parseFromString('<br>'.replace(RE_VOID_ELEMENT, replaceVoidElement), 'image/svg+xml')

works, but:

new DOMParser().parseFromString('<br/>'.replace(RE_VOID_ELEMENT, replaceVoidElement), 'image/svg+xml')

fails.

[bollwyvl]

Sure, will add some coverage.

I'm semi-disappointed we still don't have any property-based testing or overarching frontend coverage that combines jest and puppeteer outputs, but certainly won't be wading into the stack any more than i have to on this PR.

[bollwyvl]

Ok, all of the screenshots are now working (and less sensitive to scroll skew). Will merge upstream, and see if anything pops out, but no further work planned.

[bollwyvl]

This would now error if the cleaned string is not valid XML... it's harder to verify that the browser would go into the "fallback" rendering mode (the most likely failure case).

Because of that, it's probably not worth roundtripping inside the implementation, which is already pretty heavy.

[bollwyvl]

Perhaps this is something that should be hoisted up outside of a deeply-nested utils?

[krassowski]

Yes, we could add it as a galata helper in the future if it turns out useful elsewhere too. For now it's easier to do it here because this way we don't need to worry about it becoming a public API yet ;)

[bollwyvl]

hooray all 🟢

[krassowski]

Thank you @bollwyvl!

[bollwyvl]

Thanks. Alas, the wheels turn: since this was merged, https://github.com/mermaid-js/mermaid/releases/tag/v10.8.0 😿

I don't see any hard blockers/features that would require going out, but will take a look, especially to kick the tires on the screenshot approach.