When you load an svg file from html either through embed, object or img and the svg file contains external resources, those resources can't be found. They will be found if their URL is absolute or if you declare a xml:base. Interestingly, if you load the svg from a XHTML file, the resources are found. I debugged this a litte and a possible cause is in SVGImage.cpp in the function bool SVGImage::dataChanged The SVG document is created with an empty url: (loader->writer()->begin(KURL()); // create the empty document Passing the URL of the SVG file should make things work correctly... I verified that the attached code works fine in ie9 but not in the latest webkit.
Created attachment 75641 [details] test case that shows the images not being rendered
I forgot to mention that in order to make the file work in ie9 you need to make the URL in the SVG relative to the HTML. Minefield wants them relative to the SVG.
We already have a bug report for this kind of bug (still searching it). If an SVG is embedded with <img>, resources, referenced by the SVG, are not loaded. Try <object data="simple_graphics_fla_assets/svgblock_4.svg" width="..." height="..." type="image/svg+xml"/> in the mean time.
Bug 12499 seems related to this and will probably fix this as well since it's a complete rewrite. However, for the time, the simple patch I proposed will make images in external svg files work.
Are there any security implications from loading external content in embedded SVG? This seems to be a sensitive area, even though it reportedly works in other browsers.
It doesn't seem like it would introduce additional security risks. If someone wanted to do something malicious today, they could just use an absolute URL. Having support for relative URL doesn't make things less secure (In a way, it's less secure if you allow absolute paths)
The example seems to work correctly with <object>. It is expected that <img> referenced objects can not load further references. This is part of the security model.