Pale Moon forum

hi all

as a quick and easy work around for this issue until such a time as it can be fixed properly go to http://webdesigns.ms11.net/chromeditp.html and install ChromEdit Plus once installed open ChromEdit Plus and go to the userContent.css tab and add the following.
save the change and press restart

then open up CSS-Tricks.com if everything worked correctly then the above line will prevent your browser from loading the offending image but leave the site otherwise untouched thus elevating the problem, until this can get fixed properly.

Note: You don't have to install ChromEdit Plus to do this it can be done manually as well but I recommend using ChromEdit Plus as its quicker and simpler.

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.

Ladislav wrote:Sorry, but I'm not sure I understand either point.

I'm sorry but I don't have time to give you a full lecture on why letting a browser generate an image on-the-fly that is as large as the browser window will take many more cycles than rendering a raster image. But if you understand anything about how SVG filters work, then this would be self-evident.
Yes, SVG can be much smaller to download. No, SVG by definition is exceedingly more heavy on the browser because the browser will have to generate the visual image from the SVG definition.

Also, the presumption that the only rendering engines out there what you know from what happens to be the biggest browsers is a rather one-sided view.

Thirdly. I already explained that this is solved by tycho and that uplifting this to pm-release is not an option.

I did warn you that they were naive comments from an outsider! So I'm grateful for your response. To be honest, I didn't understand the Tycho comment because I didn't know what Tycho was. I assumed it was the name of a person! Anyhow, now I have found the following link it all makes sense: https://github.com/MoonchildProductions/Tycho As far as I'm concerned, it's definitely not worth wasting any effort fixing it in Pale Moon in that case. I look forward to trying out Tycho at some point in the future. Thank you.

That repository is now obsoleted by the merge back into our main repo.. We will keep it around for historical reference but all development is back on the normal repository.

I'm not sure if css-tricks is using the problematic background SVG any more, but testing against the data URI I previously posted, taken from css-tricks website before, indicates that this issue has been fixed by the arrival of version 27 of Pale Moon. Thank you to all those involved.

Ladislav wrote:I'm not sure if css-tricks is using the problematic background SVG any more, but testing against the data URI I previously posted, taken from css-tricks website before, indicates that this issue has been fixed by the arrival of version 27 of Pale Moon. Thank you to all those involved.

This was indeed addressed in v27.