Bug 18786 – Once rendered, SVG text elements removed from DOM continue to be displayed

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

[Glenn Brauen]

I have an application that manages objects and text dynamically, sometimes replacing graphics and text based on user input.  In the latest webkit nightlies and in Safari 3.1, removing <text> elements from the DOM does not remove them from the display.

I will attach a simplified SVG test file that demonstrates the problem.  In this case, I statically create a group containing graphics and text, let it render when loaded but use an onload function to start a timer that removes all elements within a specified <g> after a 1 second timeout.  The graphics disappear but the text remains visible.  Both the graphics and the text have been removed from the DOM.

This works in the latest Firefox 2 builds: both graphics and text disappear.

Although my work on this app has been dormant for a while, this used to work in Safari 3.0.  I went back as far as nightly build r29862 (January 30, 2008) and this has been broken in webkit nightlies at least that long.

[Glenn Brauen]

Created attachment 20867 [details]
SVG example that demonstrates the problem as described.

[Glenn Brauen]

This also works properly in Firefox 3.0 beta 5: both text and graphics disappear.

[Mark Rowe (bdash)]

It looks like an invalidation issue: forcing a repaint causes the text to disappear.

[Rob Buis]

Created attachment 20910 [details]
First attempt

The problem here is that the inline textbox structures are destroyed before the
repaint in RenderContainer::removeChildNode is done. That means the bounding box
for the RenderSVGInlineText is empty at the time of repaint, as well as for RenderSVGText. It seems for html text this is no problem as the layer system takes care of repainting. The patch fixes it by repainting "manually" before
destroying.
The testcase is tricky. I hope it can be done as text only dump, but I guess it is not possible as this is a rendering error.
Cheers,

Rob.

[Eric Seidel (no email)]

hyatt or mitz really should look at this craziness.

[Darin Adler]

Comment on attachment 20910 [details]
First attempt

r=me

[Rob Buis]

Landed in r34648.

[Glenn Brauen]

Using r34655, I verified this with the application I was using when I originally discovered this problem. It works as expected now.

Thanks!

Glenn