Bug 92903 - SVG fragment string is parsed incorrectly by insertHTML
Summary: SVG fragment string is parsed incorrectly by insertHTML
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Philip Rogers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-01 13:06 PDT by rlobkovsky
Modified: 2012-08-07 11:39 PDT (History)
4 users (show)

See Also:


Attachments
Testcase (3.27 KB, text/html)
2012-08-05 17:53 PDT, Philip Rogers
no flags Details
Screenshot of the bad DOM (76.67 KB, image/png)
2012-08-06 21:12 PDT, rlobkovsky
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description rlobkovsky 2012-08-01 13:06:24 PDT
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>
Comment 1 rlobkovsky 2012-08-01 14:26:56 PDT
I'm sorry, the function that has the bug is insertAdjacentHTML (used with "BeforeEnd").
Comment 2 Adam Barth 2012-08-02 14:55:31 PDT
How does Firefox behave?
Comment 3 rlobkovsky 2012-08-02 20:06:07 PDT
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.
Comment 4 Adam Barth 2012-08-02 23:26:52 PDT
Interesting.  Assigning to myself so the bug doesn't get lost.  Other folks should feel free to steal it from me.
Comment 5 Philip Rogers 2012-08-05 17:53:59 PDT
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?
Comment 6 Philip Rogers 2012-08-06 12:01:56 PDT
(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?
Comment 7 rlobkovsky 2012-08-06 16:39:51 PDT
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).
Comment 8 Philip Rogers 2012-08-06 20:19:46 PDT
(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?
Comment 9 rlobkovsky 2012-08-06 21:11:23 PDT
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.
Comment 10 rlobkovsky 2012-08-06 21:12:08 PDT
Created attachment 156854 [details]
Screenshot of the bad DOM
Comment 11 Alexey Proskuryakov 2012-08-07 11:35:40 PDT
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.
Comment 12 Philip Rogers 2012-08-07 11:39:07 PDT
(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.