haikuwebkit/LayoutTests/animations/animation-start-event-destr...

Tests element removal and hiding within the webkitAnimationStart event handler. Should not crash.

Did not crash, so PASSED
2008-12-05 Chris Marrin <cmarrin@apple.com> Reviewed by Dave Hyatt. Fix for https://bugs.webkit.org/show_bug.cgi?id=22635 For iteration and end events, previous fixes to prevent the deletion of Animation objects (ref counting and hanging onto a ref during event callbacks) was sufficient to prevent dangling pointers. But start events are sent in the styleAvailable() call, which iterates over CompositeAnimation objects, which are not ref counted. So that object can get destroyed in the event handler while still active. So I added refcounting for CompositeAnimations. Additionally, when am iterating over the CompositingAnimation list, it can be deleted, which mutates the list. So I now make one pass over the list building a vector of CompositeAnimation objects that need to be called and then iterate over that vector to make the actual calls. Finally, to make sure the lifetime of the CompositeAnimation exceeds that of the Animation objects it owns, I now keep a ref to the CompositeAnimation in the timer callback for the iteration and end events. That means I no longer need to keep a ref to the Animation objects themselves in that timer callback, since the CompositeAnimation already has one. Tests: animations/animation-iteration-event-destroy-renderer.html animations/animation-start-event-destroy-renderer.html Canonical link: https://commits.webkit.org/31263@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@39059 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2008-12-06 01:42:16 +00:00			`Tests element removal and hiding within the webkitAnimationStart event handler. Should not crash.`

			`Did not crash, so PASSED`