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
SVGRenderer is confusing to use because it retains state. If we want to use SVGRenderer asynchronously, which we are discussing doing, we will need to maintain the state differently.
Steps to Reproduce
Explain what someone needs to do in order to see what's described in Actual behavior above
Operating System and Browser
e.g. Mac OS 10.11.6 Safari 10.0
The text was updated successfully, but these errors were encountered:
If we want to use SVGRenderer asynchronously, which we are discussing doing
I'm curious what this is for! I know that fixing image dimensions from 2.0 SVGs (#58) requires loading those images to figure out their dimensions, which is asynchronous, but not sure if there's anything else happening now
Since SVG is such a flexible image format, we'd like to sandbox our handling of SVGs more thoroughly. Most of the sandboxing methods we're thinking about, like putting the measuring code into an iframe, would make more of the process asynchronous.
If that's to prevent XSS or similar attacks (as we discussed in October), then we only need to put the SVG itself inside sandbox.
We probably need to use either data URI or blob as srcdoc does not work on Legacy Edge. With sandbox="" we can disable script execution, but the parent can still access the contents via contentDocument.
SVGRenderer is confusing to use because it retains state. If we want to use SVGRenderer asynchronously, which we are discussing doing, we will need to maintain the state differently.
Steps to Reproduce
Explain what someone needs to do in order to see what's described in Actual behavior above
Operating System and Browser
e.g. Mac OS 10.11.6 Safari 10.0
The text was updated successfully, but these errors were encountered: