When a URL is posted and it makes a onebox and the image in the onebox is an SVG then Discourse is breaking the SVG in the onebox for and only on Firefox when the original SVG still works in Firefox fine otherwise. They have the same SVG commands, not scripting, fairly basic, it’s not even really minimized any to make shrinking it worthwhile.
The URL posted was (though any on that site the image breaks only in firefox):
I notice these forums did not auto-download the image instantly and optimize it as it did on the website the issue is taking place on (perhaps just a delay), the site link with an example of the issue is at:
At the very least, an option to not run the optimizer (sanitizer is fine, there is nothing to sanitize in that svg anyway) would be useful so could at least not break things.
It looks like it is removing the gaussian blur filters while the links ‘to’ those filters remain.
Manually adding the missing feGaussianBlur's back in fixes it and the SVG properly reappears.
Further testing shows that removing the filter attributes from the path’s also fixes it (though doesn’t look quite perfect due to the missing slight blur).
So as it stands, discourse is removing the gaussian blur filter elements while leaving the named references to them in the rest of the nodes. Discourse needs to either not remove the filter nodes that contains elements that are not script-issues (gaussian blur is not) or it needs to remove the associated attributes that are referencing the now missing filter elements. Leaving it in this half-state is broken.
I suspect this is a bug with imagemagick (which we use to optimize images)? As you said, somewhere in the process the filter elements are being stripped out.
Chrome/Safari tend to be a lot less strict about SVGs, so the shapes still render there — but the missing filters stop Firefox from rendering those shapes at all.
Ah, yeah imagemagick really shouldn’t be used on SVG’s, it has a lot of issues with them from personal experiences in the past and I haven’t heard of it having gotten better either (replacement projects have popped up for SVG specific handling instead, mostly in the node world for whatever reason…). I’d be fine with not optimizing SVG’s at all, just a sanitization thing to remove bad things like script tags or so forth.
Yep, that’s what I discovered as well, Firefox is strict to the spec, Chrome is… not.
I’m curious about that, what version of Firefox on which OS? I tested the latest released Firefox on both linux and Win10 and they both shows the same issue as well as tested the developer edition of firefox on Win10 with the same issue. (EDIT: I also tested Firefox on android, it also had the same issue)
I fixed the issue by allowing feGaussianBlur and filter svg elements.
Awesome thanks! I’ll pull latest shortly and will report if further issues on newly posted links.
I still find it odd that it left broken references. Even if it removes elements it should still fixup any links to them or the SVG can fail to render, as in this case.
Yeah, it’s a rather dumb whitelister that just removes non-whitelisted nodes. It doesn’t understand SVG and will thus not remove any references to the removed nodes.
Does ruby have any good SVG processors that could do a better job? I know the C++ and nodejs worlds have some pretty great ones but I haven’t really touched ruby.
EDIT: If I’m reading that whitelister right it seems to allow in a lot of security issues in regards to attributes and more… A proper sanitizer really might be better to look at…
