This is similar to the bug: http://bugs.webkit.org/show_bug.cgi?id=12065 which covers removing the animation *target* during animation. This bug refers to removing the actual animation element. See the attached test case.
Created attachment 12703 [details] test case (crashes safari)
Part of the problem is that animation notification lists are held off of the time scheduler, which is held off of the containing <svg> element. this is done because (according to the spec) each <svg> document fragment can have an independent animation timeline. (Which sorta makes sense, given the desire to build an animation editor within SVG.) So if you remove an animation element (even if it's kept alive) it will have trouble finding its <svg> element to remove itself from the notify list. The best fix is to re-work the animation notify system, as discussed in: http://bugs.webkit.org/show_bug.cgi?id=12432 But short of that, an easier fix, is to implement willRemove() and insertedIntoDocument() and add/remove the animation from the notify list on the parent <svg>. In order to support independent timelines for <svg> document fragments (as mentioned in http://bugs.webkit.org/show_bug.cgi?id=12073), we'll need to actually be careful to update the animation element if moving between <svg> document fragments (that may also affect the target of the animation, among other things, and certainly would stop the animation when removing it from one fragment before inserting it into the other).
I believe this bug is the cause of the crash here: http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/full-animate-elem-40-t.html
<rdar://problem/4960664>
<rdar://problem/4960506>
No longer a P1, since animation is disabled for now.
Animation has been re-enabled on trunk (as part of SVG_EXPERIMENTAL_FEATURES) thus this should be bumped back to P1 according to the bug guidelines (and mjs).
Animation is turned off again in trunk (a good thing). This can be pushed down to a P3.
Animation is back on. This goes back to p1.
Related to bug 12065?
I can't reproduce this using a recent checkout. Cheers, Rob.
This was fixed several month ago. Forgot to close the bug.