693428 - <use> imported via importNode has wrong base URI (the URI of the document it was imported from, not of the new document)

Status: RESOLVED DUPLICATE of bug 1357432

(Core :: SVG, defect)

Description

[Martin Hejral]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

At first, one note: this rendering bug appears with FF version 7, older versions works, also WebKit works with no problem, so I guess the correction should be easy.

1) SVG image xref-b.svg contains 2 included <image href="xref-a.svg">
2) web app loads xref-b.svg by AJAX and append new SVG object tree to the existing current document DOM
3) web app change file path to the <image href="xref-path/xref-a.svg">
4) the bug appears to be in connection with <symbol> using

Please note, that is about very complex SVG web app, which have very good reason to do this little bit complicated algorithm :)


Actual results:

You will get a little strange debug output:

[21:34:15.296] GET http://svg.mysteria.cz/ff/ff-svg-ajax-bug.svg [HTTP/1.1 304 Not Modified 62ms]
[21:34:15.420] GET http://svg.mysteria.cz/ff/xref-b.svg [HTTP/1.1 304 Not Modified 31ms]
[21:34:15.492] GET http://svg.mysteria.cz/ff/xref-path/xref-a.svg [HTTP/1.1 304 Not Modified 16ms]
[21:34:15.543] GET http://svg.mysteria.cz/ff/xref-a.svg [HTTP/1.1 404 Not Found 4188ms]
[21:34:19.705] GET http://svg.mysteria.cz/ff/xref-a.svg [HTTP/1.1 404 Not Found 3031ms]

And 2nd <image> placed inside <symbol> will NOT be rendered...


Expected results:

All 2 <image>s should be rendered.

Comment 1

[Martin Hejral]

I created minimized testcase here:
http://svg.mysteria.cz/ff/ff-svg-ajax-bug.svg



Here is placed file with external linked images:
http://svg.mysteria.cz/ff/xref-b.svg

<symbol id='xref-a' overflow='visible'><desc>DXF block 'xref-a'.</desc>
<image id='2-image-inside-symbol' x='-500' y='-500' width='1000' height='1000' xlink:href='xref-a.svg'/>
</symbol>

<image id='1-standard-image' x='-50' y='-50' width='100' height='100' xlink:href='xref-a.svg'/>

<use xlink:href='#xref-a' id='x2' transform='translate(0,0) scale(.0707 .0707)'/>



AT last here is included SVG file with simple red box:
http://svg.mysteria.cz/ff/xref-path/xref-a.svg

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
<svg viewBox='0 0 1000 1000' overflow='visible' version='1.0' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' image-rendering='optimizeQuality' shape-rendering='optimizeQuality'>
<title>generic/xref-a.dxf :: converted to SVG vector graphic</title>
<rect x='0' y='0' width='1000' height='1000' fill='#F00' opacity='0.5'/>
</svg>

Comment 2

[Daniel Holbert [:dholbert]]

possibly duplicate of bug 692506? (based on it being a regression with <image> in Firefox 7)

Comment 3

[Daniel Holbert [:dholbert]]

Martin, could you try a nightly build and see if this is fixed there?

http://nightly.mozilla.org/

Comment 4

[Martin Hejral]

Attachment: correct-rendering of the testcase

Comment 5

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> Martin, could you try a nightly build and see if this is fixed there?

Hello Daniel, many thanks for the quick reply.

I have JUST done test with Nightly 10.0a1 (2011-10-10)

Negative. As expected.

By my opinion https://bugzilla.mozilla.org/show_bug.cgi?id=692506
is another issue. In our case is AJAX loaded sub-tree correctly included in current document. 

(1st <image id='1-standard-image' x='-50' y='-50' width='100' height='100' xlink:href='xref-a.svg'/> is correctly rendered.) 

But 2nd <image> inside <symbol>
<symbol id='xref-a' overflow='visible'><desc>DXF block 'xref-a'.</desc>
<image id='2-image-inside-symbol' x='-500' y='-500' width='1000' height='1000' xlink:href='xref-a.svg'/>
</symbol>

NOT!

Comment 6

[Daniel Holbert [:dholbert]]

Ok -- so just to be clear, the issue is that the inner lighter-red rect (inside the ellipse) is missing?

I actually see that behavior in Firefox 4.0, too (as well as today's nightly)...
Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

In what older Firefox version do you get working behavior?

Comment 7

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> possibly duplicate of bug 692506? (based on it being a regression with
> <image> in Firefox 7)

I do not think so. I am convinced that problem is how <symbol>s are processed...

Please note 2nd <image> inside <symbol>!!
(JS changes xlink:href='xref-a.svg' INSIDE <symbol>)

<symbol id='xref-a' overflow='visible'><desc>DXF block 'xref-a'.</desc>
<image id='2-image-inside-symbol' x='-500' y='-500' width='1000' height='1000' xlink:href='xref-a.svg'/>
</symbol>

<use xlink:href='#xref-a' id='x2' transform='translate(0,0) scale(.0707 .0707)'/>

Comment 8

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> Ok -- so just to be clear, the issue is that the inner lighter-red rect
> (inside the ellipse) is missing?

I am not sure about older versions, but ABSOLUTELY sure it worked in FF 6 (maybe 5).

PS: see also https://bugzilla.mozilla.org/show_bug.cgi?id=272288

Comment 9

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> the issue is that the inner lighter-red rect
> (inside the ellipse) is missing?

Yes, exactly

Comment 10

[Martin Hejral]

Attachment: main SVG document with JS AJAX code

Comment 11

[Martin Hejral]

Attachment: SVG image xref-b.svg contains 2 included <image href="xref-a.svg">

Comment 12

[Martin Hejral]

Attachment: SVG file with simple red box

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Martin Hejral from comment #8)
> (In reply to Daniel Holbert [:dholbert] from comment #6)
> > Ok -- so just to be clear, the issue is that the inner lighter-red rect
> > (inside the ellipse) is missing?
> 
> I am not sure about older versions, but ABSOLUTELY sure it worked in FF 6
> (maybe 5).

Your linked testcase (http://svg.mysteria.cz/ff/ff-svg-ajax-bug.svg) is broken for me in Firefox 6, too....*  Are you sure it worked for you there?  (maybe something changed in the testcase since you tested it on Firefox 6?)

Sorry for pushing on this point -- in cases of regressions, it's very helpful to find the point at which something broke, and in this case, it looks so far like this has never worked. :)

*obtained Firefox 6 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/6.0-candidates/build1/

Comment 14

[Daniel Holbert [:dholbert]]

(confirmed that Opera & Chromium both show 2 nested red rects -- though in Chromium, the rects are much smaller -- the larger rects's width is about the same as the circle's radius)

Comment 15

[Daniel Holbert [:dholbert]]

(Martin: also -- if you can do any further simplification to your live testcase (and post a link to the updated version), that'd definitely be helpful in getting to the bottom of this.)

Comment 16

[Boris Zbarsky [:bzbarsky]]

For what it's worth, on http://svg.mysteria.cz/ff/ff-svg-ajax-bug.svg I get identical rendering in Firefox 4, 5, 6, 7, and in nightlies...  So this definitely doesn't look like it ever worked.

Comment 17

[Boris Zbarsky [:bzbarsky]]

So the key part here is this:

  <use xlink:href="#xref-a"/>

not actually rendering the image, right?  Looks like we correctly clone that subtree, have an <image> in the anonymous content with a non-null mCurrentRequest, and it has an SVGImageFrame.

We also enter nsSVGImageFrame::PaintSVG for that cloned image.  But then TransformContextForPainting() returns false, so we return early from that method without painting.

Comment 18

[Boris Zbarsky [:bzbarsky]]

And that happens because NS_FAILED(mImageContainer->GetWidth(&nativeWidth)) tests true.

And _that_ happens because on that particular image mError is set to true.

This image container also happens to be TYPE_RASTER.

And if I look at the mCurrentRequest of the <image>, its URI is http://svg.mysteria.cz/ff/xref-a.svg

Which is in fact 404, and would lead to a RasterImage with mError set.

Comment 19

[Boris Zbarsky [:bzbarsky]]

And the reason for that is that the <use> seems to be finding the <symbol> it finds in the _resource_ document with URI http://svg.mysteria.cz/ff/xref-b.svg

And _that_ happens because the <use> was imported into the document being viewed, which used importNode, which internally clones.  And cloning a <use> sets its mOriginal to the thing it's cloned from and then nsSVGUseElement::LookupHref does:

  nsCOMPtr<nsIURI> baseURI = mOriginal ? mOriginal->GetBaseURI() : GetBaseURI();

In this case mOriginal is living in the XHR response document, and its base URI is the URI of that document...

We really need to only set mOriginal for use-clones caused by <use>, I would think...  At the very least we need to clear mOriginal out on ownerDocument changes, just like we clear it out on href changes.

So no need to use AJAX to reproduce this bug; just need to importNode a <use> from a document with one base URI to a document with a different base URI.

Comment 20

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #13)
> Sorry for pushing on this point -- in cases of regressions, it's very
> helpful to find the point at which something broke, and in this case, it
> looks so far like this has never worked. :)

Daniel, I very well understand on this point. I made heavy effort to create simplified code. The project I work is really complex JS code which works with huge SVG files -- I carefully picked out code to demonstrate the problem.

Now I will add an attachments showing network communication in FF6 and FF7. Also an less stripped JS — perhaps this helps and you will see something I omit. Thanks for you work.

Comment 21

[Martin Hejral]

Attachment: FF6: correct rendering

Comment 22

[Martin Hejral]

Attachment: FF7: incorrect - complex map on background missing

complex map on background is included by this SVG code:

<symbol id='BVA008VN01' overflow='visible'>
<image x='110.10' y='-818.70' width='884.10' height='801.70' xlink:href='BVA008VN01.svg' xlink:title='This image is DXF external reference file.'/>
</symbol>

Comment 23

[Martin Hejral]

Attachment: part of original JS

Comment 24

[Martin Hejral]

Attachment: the same case in Safari 5: network comm.

Comment 25

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #14)
> (confirmed that Opera & Chromium both show 2 nested red rects -- though in
> Chromium, the rects are much smaller -- the larger rects's width is about
> the same as the circle's radius)

It is the bug of WebKit, I think

Comment 26

[Martin Hejral]

(In reply to Daniel Holbert [:dholbert] from comment #13)
> (In reply to Martin Hejral from comment #8)
> > (In reply to Daniel Holbert [:dholbert] from comment #6)
> > > Ok -- so just to be clear, the issue is that the inner lighter-red rect
> > > (inside the ellipse) is missing?
> > 
> > I am not sure about older versions, but ABSOLUTELY sure it worked in FF 6
> > (maybe 5).
> 
> Your linked testcase (http://svg.mysteria.cz/ff/ff-svg-ajax-bug.svg) is
> broken for me in Firefox 6, too....*  Are you sure it worked for you there? 
> (maybe something changed in the testcase since you tested it on Firefox 6?)

Daniel, I am really sorry that I'm not able to find the difference between our complex app. and simplified testcase here -- for why our images is loaded in FF6, and why behaviour is different with my minimized testcase. I hope that idea of Boris will help...

Comment 27

[Daniel Holbert [:dholbert]]

Martin: Thanks for your work in reducing the testcases from your web app! It sounds like Boris has identified the root of the problem, yes. (in comment 19 & his updated bug-summary)  Hopefully someone can fix it soon...

Comment 28

[Martin Hejral]

(In reply to Boris Zbarsky (:bz) from comment #19)
> And the reason for that is that the <use> seems to be finding the <symbol>
> it finds in the _resource_ document with URI
> http://svg.mysteria.cz/ff/xref-b.svg
> 
> And _that_ happens because the <use> was imported into the document being
> viewed, which used importNode, which internally clones.  And cloning a <use>
> sets its mOriginal to the thing it's cloned from and then
> nsSVGUseElement::LookupHref does:
> 
>   nsCOMPtr<nsIURI> baseURI = mOriginal ? mOriginal->GetBaseURI() :
> GetBaseURI();
> 
> In this case mOriginal is living in the XHR response document, and its base
> URI is the URI of that document...

Boris, thanks. It looks like good idea. But I'm not sure: explains this why not help to change href manually using this JS?

var nodeList = importedNode.getElementsByTagNameNS("*","image");
var node = nodeList.item(0);
node.setAttributeNS(xlinkNS,"href","xref-path/xref-a.svg");

Comment 29

[Robert Longson [:longsonr]]

The example seems to work now.

Comment 30

[Daniel Holbert [:dholbert]]

Fix range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=91c19f2d71f35f1bb4ee5325870275d648b0c2db&tochange=032d23aaffe3a22a2b158e2d30bc26183799bed0

--> Duping forward to bug 1357432