Moonchild wrote:So, in the interim, you can use e.g. a content blocker to block the SVG background, which is very presumptuous (and risky) web design to begin with -- I can imagine other rendering engines also having massive problems with this...
Sorry, but I'm not sure I understand either point. Surely, use of a tiny (10's of bytes) plain-text svg image is better than making the end user download a much larger jpeg or png binary blob. I imagine that the only presumption the designer will have had is that doing so would work effectively in the browser without exposing the end user to any risks? Why should an svg be more risky than a jpeg or PNG? It's what the browser chooses to do with it that makes it risky it not. Perhaps you meant risky from the point of view of assuming that the browser would provide support for the particular SVG filters etc. that were used? If so, you'd perhaps expect that the image wouldn't be rendered, not that it would make the web page unusable or the browser hang.
We've already established that Pale Moon is the only browser that has an issue with this particular image. So no, other rendering libraries are not having a problem with this. If they did, they've already dealt with it.
Naive questions from an outsider follow: Since Firefox doesn't have the same rendering problems, can't the same approach that it has used be applied? Perhaps there are some SVG library code changes that could be pulled in? I sounds from the above like Pale Moon is taking it's own approach to rendering. Wouldn't it be better from a security point of view to use a common library, if one exists, so that there is a larger user base to find a fix issues?
Sorry if my questions are way off the mark. No need to waste your time responding if you think they are. Thank you for looking into this issue.