739726 - Nested SVG using image tag fails to display

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Ezzy]

Attachment: nestedSVGbug.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5 Safari/534.55.3

Steps to reproduce:

Attempted to display SVG containing SVG (using image) which contains svg (using image)

(file to display is path.svg)

Included is a zip folder of files that demonstrate the problem.  


path.svg
 contains drawing commands
 image circle.svg

circle.svg
  contains drawing commands
  image rect.svg

rect.svg
 contains drawing commands

path1.svg 
  contains drawing commands
  image rect.svg
  image circle.svg

path2.svg
  contains drawing commands
  image rect.svg


file name and contents below (as well as zipped attachment)


filename:circle.svg
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 300 100">
    <title>Circle with image Rect SVG</title>
    <a xlink:href="rect.svg" xlink:title="Link to rect alone from circle">
        <circle  cx="50" cy="50" r="50" stroke="rgb(255,228,244)" stroke-width="5" stroke-dasharray="40,20" fill="none" />
        <image x="0" y="0" xlink:href='rect.svg' width='100%' height='100%'/>
        </a>
</svg>

filename:path1.svg
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 300 100">
    <title>Main Svg containing imaged circle containing imaged rect</title>
    <a xlink:href="path2.svg" xlink:title="Link to pathexample">
        <path d="M 250 0 l -50 100 h 100z" fill="blue"/>
        <image x="0" y="0" xlink:href='rect.svg' width='100%' height='100%'/>
        <image x="0" y="0" xlink:href='circle.svg' width='100%' height='100%'/>
    </a>
</svg>

filename:path2.svg
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 300 100">
    <title>Main Svg containing path containing imaged rect</title>
    <a xlink:href="path.svg" xlink:title="Link to nested path">
        <path d="M 250 0 l -50 100 h 100z" fill="blue"/>
        <image x="0" y="0" xlink:href='rect.svg' width='100%' height='100%'/>
    </a>
</svg>

filename:path.svg
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 300 100">
    <title>Main Svg containing imaged circle containing imaged rect</title>
    <a xlink:href="circle.svg" xlink:title="Link to circle">
        <path d="M 250 0 l -50 100 h 100z" fill="blue"/>
        <image x="0" y="0" xlink:href='circle.svg' width='100%' height='100%'/>
    </a>
</svg>

filename:rect.svg
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        viewBox="0 0 300 100">
    <title>Rect with style sheet</title>
    <a xlink:href="path1.svg" xlink:title="Link to aggrigate containing path containting circle containing Rect)">
        <rect  x="100" y="0" width="150" height="100" fill="rgb(5,228,4)"/>
    </a>
</svg>



Actual results:

Only displayed drawing commands from path.svg and drawing commands from first included svg.

(demonstrated by looking at path.svg)
files path1.svg show what should be displayed (by copying other svg content) and path2.svg shows missing subset.


Tested on Mac firefox 11.0 as well as linux firefox 11.0 (ubuntu 12.04)
fails in different way on safari and chrome (webkit).

Works properly on OPERA.  






Expected results:

Should display all svg images using recursion.  Why should user be aware of SVG structure?

Opera displays image correctly.

Comment 1

[Boris Zbarsky [:bzbarsky]]

SVG images (loaded via <html:img> or <svg:image>) are not allowed to link to any sort of external references, because that introduces security issues, unfortunately...  And yes, Opera suffers from those issues.

Comment 2

[Ezzy]

@ Boris Zbarsky (:bz) 

I am confused, as this displays one level down, but not more..
so, if linking is a security issue (I have no doubt of this) then...
the first link should fail.. (and ideally give a security warning).

but now, if just have two files  
OUTER
INNER

it loads BOTH

if have three
OUTER1
OUTER
INNER
it loads 
OUTER1
OUTER

so... I do not understand the lack of consistency.

I would think that a SVG loading from the same URI space should load, and from different could not load depending on security preferences.

The SVG allows linked SVG's and they are a space and time saver when reusing the same element over and over.

I understand that a SVG with an external link can be an issue.  But on the same server, same URI?

Thanks

Comment 3

[Daniel Holbert [:dholbert]]

It's a security issue for SVG-as-an-image.  Your outermost SVG is being viewed as a document, so it's allowed to do some things (load external resources, run scripts, handle click interactions) that we disallow inside of SVG *as an image*.

See bug 628747 comment 0 for an example of the badness this would cause.

> I would think that a SVG loading from the same URI space should load

Sadly, this isn't enough in general -- as noted in bug 628747 comment 3, open redirectors can unknowingly open themselves up to having _every_ URI be presentable as a same-domain resource.
e.g. something like
 <image xlink:href="http://mydomain.com/something_stupid.cgi?uriToGet=evilhacker.com/evil.png">
looks like it comes from mydomain.com, which would mean the same-domain restriction on mydomain.com would be meaningless.

Comment 4

[Daniel Holbert [:dholbert]]

two possible workarounds for you:
  - <use xlink:href="foo.svg#rootSVGID"> instead of <image xlink:href="foo.svg"> -- I think that should work recursively (though I'm not sure)

  - You could get e.g. path.svg to work if you encoded rect.svg as a data URI[1] and referenced it that way instead.  One example of that in our source tree:
 http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/svg/as-image/svg-image-datauri.svg
 (That cloud-hosted version isn't served as SVG as some reason, so it just renders as text (for me at least), but if you save it locally you should be able to try it out.)

[1] at http://software.hixie.ch/utilities/cgi/data/data

Comment 5

[Daniel Holbert [:dholbert]]

You also could potentially replace <image> with <embed> or <iframe>, inside of a foreignObject element.  Both <embed> & <iframe> will load the external resource as a _document_ instead of an image, which means we'll grant it the permission to load external resources.

Comment 6

[Masatoshi Kimura [:emk]]

Is it impossible to detect and prevent redirecting to external resources?
Even if it's impossible right now, implementing the detection looks a valid enhancement request to me.

Comment 8

[ytrezq]

(In reply to On vacation August 4-25.  Please mail manually if really needed. from comment #1)
> And yes, Opera suffers from those issues.

It is not an issue for presto based versions of Opera, as the outermost document (whether html or svg) inherit the security context created by the first svg loaded by an image.
I tried it on 12.50 by using two nested iframe using external resources from an svg used as an image ——> you can’t run scripts in the outermost.

It’s not a privacy issue as I don’t know any site that allow uploading svg as an image in comments and disallow external image sharing at the same time.

Looks like blink and gecko partially try to disable external resource loading (creating a second point of failure by the risk of an external resource being loaded) instead of keeping locking the security context whatever happens, when an svg is loaded with an <img>

Comment 9

[Robert Longson [:longsonr]]

The privacy leak does not require running scripts. Some possibilities are described here: https://bugzilla.mozilla.org/show_bug.cgi?id=628747#c0

If you want to discuss this further please use the newsgroup(https://groups.google.com/forum/#!forum/mozilla.dev.tech.svg) rather than bugzilla.

Comment 10

[ytrezq]

(In reply to Robert Longson from comment #9)
> The privacy leak does not require running scripts. Some possibilities are
> described here: https://bugzilla.mozilla.org/show_bug.cgi?id=628747#c0
Never told of running scripts in the case of privacy. There are no platforms which allow to upload svg for <img> and that disallow external image at the same time.