Closed Bug 693428 Opened 8 years ago Closed 2 years ago

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

Categories

(Core :: SVG, defect, major)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 1357432

People

(Reporter: martin.hejral, Unassigned)

References

()

Details

Attachments

(8 files)

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.
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>
OS: Windows XP → All
Hardware: x86 → All
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Version: 7 Branch → Trunk
Severity: normal → major
Component: SVG → General
Product: Core → Firefox
Version: Trunk → 7 Branch
possibly duplicate of bug 692506? (based on it being a regression with <image> in Firefox 7)
Martin, could you try a nightly build and see if this is fixed there?

http://nightly.mozilla.org/
Component: General → SVG
Product: Firefox → Core
(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!
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?
(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)'/>
(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
(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
(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/
Version: 7 Branch → Trunk
(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)
(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.)
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Summary: rendering of SVG with included <image>s fail when loaded by AJAX → <use> imported via importNode has wrong base URI (the URI of the document it was imported from, not of the new document)
(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.
Attached image FF6: correct rendering
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>
Attached file part of original JS
(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
(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...
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...
Attachment #566274 - Attachment mime type: application/octet-stream → text/plain
(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");
The example seems to work now.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.