Bug 92903 – SVG fragment string is parsed incorrectly by insertHTML

• Component: SVG
• Status: RESOLVED WORKSFORME

I have a (valid) string describing an inline SVG (pasted at the end). When used in a standalone SVG file, it is rendered correctly. However, when using insertHTML to append it to a DIV, the resulting DOM is wrong. The first linearGradient contains all the rest of the elements, instead of being their sibling under the SVG header element. In other words, the closing tag of the first linearGradient is being ignored.

SVG string:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 263 112" onclick="MG.forms.FormPanel.generateTileEvent('', '0','gd3','6')" id="ext-gen1104"><linearGradient id="tileBGgrad" x1="0%" y1="0%" x2="100%" y2="0%"><stop stop-color="rgb(255,255,255)" offset="0%"></stop><stop stop-color="rgb(0,0,255)" offset="100%"></stop></linearGradient><rect x="0" id="bg" y="0" width="263" height="112" style="fill:url(#tileBGgrad)"></rect><g id="ext-gen1105"><rect x="6" y="78" width="72" height="21" fill="Transparent"></rect><clipPath id="ck0clipCB"><rect x="7" y="79" width="14" height="14"></rect></clipPath><image x="7" y="31" width="14" height="84" overflow="hidden" preserveAspectRatio="xMaxYMin slice" clip-path="url(#ck0clipCB)" xlink:href="Content/images/checkbox_sprite.gif" onclick="var event = arguments[0] || window.event; MG.forms.FormPanel.generateTileEvent('ck0', '0','gd3','6'); event.stopPropagation();"></image><clipPath id="ck0clip"><rect x="21" y="79" width="56" height="19"></rect></clipPath><text x="21" dominant-baseline="hanging" y="80" clip-path="url(#ck0clip)" text-anchor="start" fill="#555555">Super User</text></g><g onclick="var event = arguments[0] || window.event; if (evt.detail == 2) MG.forms.FormPanel.generateTileEvent('ed1','0','gd3','6'); event.stopPropagation();" id="ext-gen1106"><rect x="84" y="11" width="97" height="25" stroke="#999999" stroke-width="1" fill="#F0F0F0"></rect><clipPath id="ed1clip"><rect x="85" y="12" width="95" height="23"></rect></clipPath><text dominant-baseline="hanging" y="13" x="85" clip-path="url(#ed1clip)" text-anchor="start" fill="#555555">SL_Internal</text></g><g onclick="var event = arguments[0] || window.event; if (evt.detail == 2) MG.forms.FormPanel.generateTileEvent('fc2','0','gd3','6'); event.stopPropagation();" id="ext-gen1107"><rect x="85" y="46" width="96" height="50" stroke="#999999" stroke-width="1" fill="#F0F0F0"></rect><clipPath id="fc2clip"><rect x="86" y="47" width="94" height="48"></rect></clipPath><text dominant-baseline="hanging" y="48" x="134" clip-path="url(#fc2clip)" text-anchor="middle" fill="#555555">Last updated: 9/7/2005
<tspan x="134" dy="1em"> 3:30:02 PM</tspan></text></g><g id="ext-gen1108"><linearGradient id="lb3grad" x1="0%" y1="0%" x2="0%" y2="100%"><stop stop-color="rgb(255,0,0)" offset="0%" stop-opacity="0.50"></stop><stop stop-color="rgb(255,255,255)" offset="100%"></stop></linearGradient><rect x="10" y="11" width="65" height="25" fill="none" style="fill:url(#lb3grad)"></rect><clipPath id="lb3clip"><rect x="11" y="12" width="63" height="23"></rect></clipPath><text dominant-baseline="hanging" y="13" x="74" clip-path="url(#lb3clip)" text-anchor="end" fill="#555555">Test 1:</text></g><g id="ext-gen1110"><rect x="6" y="46" width="72" height="25" fill="Transparent"></rect><clipPath id="lb4clip"><rect x="7" y="47" width="70" height="23"></rect></clipPath><text id="ext-gen1109" style="font-family: Arial, Helvetica, 'URW Gothic L', sans-serif; font-size: 10pt; font-weight: normal; font-style: normal; " dominant-baseline="hanging" y="48" x="77" clip-path="url(#lb4clip)" text-anchor="end" fill="#555555">Test 2:</text></g><g id="ext-gen1111"><rect x="201" y="10" width="53" height="60" fill="Transparent"></rect><image x="201px" y="10px" width="53px" height="60px" xlink:href="Content/images/warning.png"></image><clipPath id="lb5clip"><rect x="202" y="11" width="51" height="58"></rect></clipPath><text dominant-baseline="hanging" y="12" x="253" clip-path="url(#lb5clip)" text-anchor="end" fill="#555555">:</text></g></svg>

I'm sorry, the function that has the bug is insertAdjacentHTML (used with "BeforeEnd").

[Adam Barth]

How does Firefox behave?

Firefox produces the correct DOM, i.e.: the first linearGradient element contains only the two stop elements, and the rest of the elements in the SVG are siblings/cousins of the linearGradient instead of being its children.

[Adam Barth]

Interesting.  Assigning to myself so the bug doesn't get lost.  Other folks should feel free to steal it from me.

[Philip Rogers]

Created attachment 156578 [details]
Testcase

Thank you for taking the time to file this but I'm unable to reproduce it. Do you mind looking at my repro case and seeing if it differs from your test?

[Philip Rogers]

(In reply to comment #5)
> Created an attachment (id=156578) [details]
> Testcase
> 
> Thank you for taking the time to file this but I'm unable to reproduce it. Do you mind looking at my repro case and seeing if it differs from your test?

One other possibility: I remember seeing similar issues ~6months ago where the inspector incorrectly displayed some parts of the SVG tree. The bug report says you're on WebKit nightly--is this true or are you using a stable/dev version Chrome or Safari?

I'm on a stable version of Safari (5.1.7) -- the next oldes option in the versions dropdown was something really old, like circa Safari 3 I think.
And it's definitely not the inspector -- the SVG is not rendered (since all the nodes end up in a non-graphical element).

[Philip Rogers]

(In reply to comment #7)
> I'm on a stable version of Safari (5.1.7) -- the next oldes option in the versions dropdown was something really old, like circa Safari 3 I think.

This certainly isn't your fault. Our default version info is not very user friendly. I'll follow up and see if we can get those changed.

> And it's definitely not the inspector -- the SVG is not rendered (since all the nodes end up in a non-graphical element).

Back to the bug..

I tested this with an older version of Safari and wasn't able to reproduce the bug there either.

My best guess is that the steps above are not sufficient to trigger the bug. Can you provide an HTML file that demonstrates the bug? Or can you find how your application and the Testcase I attached are different?

I don't think I made myself clear... The attached testcase reproduces the bug on my Safari install. I don't know if it's a Windows vs. Mac thing, or what. The result of the faulty DOM is a blank SVG due to the wrong element nesting, even with your testcase. Please see the attached screenshot.

Created attachment 156854 [details]
Screenshot of the bad DOM

[Alexey Proskuryakov]

I can reproduce with Philip's test case in Safari 5.1.x, but not in Safari 6. So, sounds like this has been fixed in WebKit long ago.

[Philip Rogers]

(In reply to comment #11)
> I can reproduce with Philip's test case in Safari 5.1.x, but not in Safari 6. So, sounds like this has been fixed in WebKit long ago.

I was also able to reproduce this on Safari 5.1.7/Windows (but not the WebKit rev, strangely). In any case, it looks like this has been fixed and will be released with Safari 6.