Bug 63646 – Crash in SVGUseElement::updateContainerOffsets on <use> with no parent

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Tim Horton]

Created attachment 99126 [details]
test case

The attached SVG crashes WebKit in SVGUseElement::updateContainerOffsets.

In a debug build, we get an ASSERTion failure saying that the <use> element doesn't have a parentNode.

[Tim Horton]

<rdar://problem/9630764>

[Nikolas Zimmermann]

> Created an attachment (id=99126) [details]
> test case
> 
> The attached SVG crashes WebKit in SVGUseElement::updateContainerOffsets.
Excellent catch. Tim, where have you been all the years? :-) Your work is highly appreciated.

> 
> In a debug build, we get an ASSERTion failure saying that the <use> element doesn't have a parentNode.
That's not correct, the <use> has a parentNode - it's shadow tree root element (living in the <use> renderer) lost its parent.

Do you feel like debugging? :-)

[Tim Horton]

(In reply to comment #2)
> > Created an attachment (id=99126) [details] [details]
> > test case
> > 
> > The attached SVG crashes WebKit in SVGUseElement::updateContainerOffsets.
> Excellent catch. Tim, where have you been all the years? :-) Your work is highly appreciated.
> 
> > 
> > In a debug build, we get an ASSERTion failure saying that the <use> element doesn't have a parentNode.
> That's not correct, the <use> has a parentNode - it's shadow tree root element (living in the <use> renderer) lost its parent.

Alright, that makes a lot more sense.

> Do you feel like debugging? :-)

Now that you've explained it correctly, I think it'll be easier to figure it out, so sure! (I couldn't make my explanation make any sense given what was actually going on in the document, but I figured someone else would have some insight, and you did!)

[Tim Horton]

Nope, I think this one is beyond me for now.

It's clear that it's because we're unlinking the middle use in the chain from its child content, but I can't follow exactly where we diverge from the case where the first use in the chain (the last one in the file) doesn't exist.

I don't know enough about the shadow tree and friends to track this one down yet.

Feels like we're just failing to detachInstance() or something, but I'm not sure where.

[Rob Buis]

Created attachment 99658 [details]
Patch

[Tim Horton]

(In reply to comment #5)
> Created an attachment (id=99658) [details]
> Patch

Rob's patch is certainly sufficient to fix the symptom; should we at least take this for now and figure out the root cause later?

[Nikolas Zimmermann]

(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=99658) [details] [details]
> > Patch
> 
> Rob's patch is certainly sufficient to fix the symptom; should we at least take this for now and figure out the root cause later?

Are we in hurry with a fix for this? If so yes, but I don't think so. We should rather find out if the null parentNode is "okay", or not. Rob?

[Rob Buis]

Created attachment 101844 [details]
Patch

[Rob Buis]

Hi Niko,

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Created an attachment (id=99658) [details] [details] [details]
> > > Patch
> > 
> > Rob's patch is certainly sufficient to fix the symptom; should we at least take this for now and figure out the root cause later?
> 
> Are we in hurry with a fix for this? If so yes, but I don't think so. We should rather find out if the null parentNode is "okay", or not. Rob?

I uploaded a new patch, hopefully this fix is better and the ChangeLog should explain the problem.
Cheers,

Rob.

[Rob Buis]

Landed in r91653.