Why is my SVG document using a copy of itself in place of an image in Google Chrome?

I have an SVG document here

On firefox, everything works as expected. However, google chrome appears to think this line:

<image ... xlink:href="/textures/Cube top.png" />

references http://minecraft-cube.comuv.com/index.svg,

not http://minecraft-cube.comuv.com/textures/Cube top.png, resulting in unexpected recursion.

Obviously, I'd much prefer it if it used the image I specify.

What is goin开发者_运维技巧g on here?

EDIT: Filed bug #68732 in Chrome. May still be doing something wrong though.

I think that your problem exists elsewhere. Here is a simplified version of your document that correctly shows the linked image:

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" viewBox="0 0 48 84" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <defs>
        <g id="top-tile">
            <image width="1" height="1" x="-0.5" y="-0.5" class="face"
             xlink:href="http://minecraft-cube.comuv.com/textures/Cube top.png" />
        </g>
    </defs>
    <g transform="scale(16)">
        <g transform="translate(1.5, 1.5)">
            <use xlink:href="#top-tile" />
        </g>
    </g>
</svg>

If I use absolute paths to your images and remove the clip-path attributes I see your images in Safari and Chrome. If I put the clip-path back in I see all black fill in Safari, but what is presumably correct in Chrome. If you put in absolute paths (e.g. xlink:href="http://minecraft-cube.comuv.com/textures/Cube top.png") does it work for you in Chrome?

Now that I see what you are trying to make, I wish I could give you +2 for making a fold-up Minecraft tile :)

Edit Next Steps:

1. Remove the space from your file name.
2. Try using a relative path instead of absolute.
3. Now that we know better the core issue, Google for more answers (I haven't found any)
4. Pare it down to a trivial test case and file a bug against Chrome.

Edit 2: As shown in the updated question, @Eric did file a bug against Chrome. As shown in that bug report, newer versions of Chrome display the intended result. Further, a slightly modified test case using explicit pixel-based image height and width, and pixel-based SVG viewBox and dimensions works in all browsers tested.