haikuwebkit/LayoutTests/webanimations/leak-document-with-web-anim...

12 lines
277 B
Plaintext
Raw Permalink Normal View History

[Web Animations] Using a Web Animation leaks the Document https://bugs.webkit.org/show_bug.cgi?id=187088 <rdar://problem/41392046> Reviewed by Darin Adler. Source/WebCore: Test: webanimations/leak-document-with-web-animation.html We need to ensure that any remaining animation is cleared when the DocumentTimeline is detached from its Document. We rename WebAnimation::prepareAnimationForRemoval() to WebAnimation::remove() since it really actively disassociates the animation from its timeline. An earlier version of this patch (r233349) was rolled out due to crashes caught in the ASan configuration. The following changes were made to make it safe: - We protect the DocumentAnimationScheduler instance in displayRefreshFired() against code that might run in a requestAnimationFrame() callback that would trigger the object to be deleted. - We protect the WebAnimation instance in remove() against setEffectInternal() or setTimelineInternal() potentially causing the object to be deleted. Similar protections were addede to setEffect() and setTimeline(). - We changed ~DocumentTimeline() to a default implementation to ensure it calls ~DisplayRefreshMonitorClient() to avoid callbacks after the object has been marked for deletion. * animation/AnimationTimeline.cpp: (WebCore::AnimationTimeline::removeAnimationsForElement): We no longer need the call to removeAnimation() since the new WebAnimation::remove() method will also set the timeline to null which will eventually call removeAnimation() on the disassociated timeline. * animation/DeclarativeAnimation.cpp: (WebCore::DeclarativeAnimation::remove): (WebCore::DeclarativeAnimation::prepareAnimationForRemoval): Deleted. * animation/DeclarativeAnimation.h: * animation/DocumentAnimationScheduler.cpp: (WebCore::DocumentAnimationScheduler::displayRefreshFired): * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::detachFromDocument): Call remove() on all known animations. (WebCore::DocumentTimeline::~DocumentTimeline): Deleted. * animation/WebAnimation.cpp: (WebCore::WebAnimation::remove): Set the timeline to null to fully disassociate this animation from its timeline. (WebCore::WebAnimation::setEffect): (WebCore::WebAnimation::setEffectInternal): (WebCore::WebAnimation::setTimeline): Factor the internal timeline-association code out of this JS API method so that we can call this code without any JS-facing implications. (WebCore::WebAnimation::setTimelineInternal): (WebCore::WebAnimation::prepareAnimationForRemoval): Deleted. * animation/WebAnimation.h: LayoutTests: * webanimations/leak-document-with-web-animation-expected.txt: Added. * webanimations/leak-document-with-web-animation.html: Added. * webanimations/resources/web-animation-leak-iframe.html: Added. Canonical link: https://commits.webkit.org/202654@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@233583 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-07-06 18:31:12 +00:00
This test asserts that Document doesn't leak when a Web Animation is created.
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
The iframe has finished loading.
WebAnimation should never prevent entering the back/forward cache https://bugs.webkit.org/show_bug.cgi?id=203088 <rdar://problem/56374249> Patch by Antoine Quint <graouts@apple.com> on 2019-10-29 Reviewed by Antti Koivisto. Source/WebCore: Test: webanimations/animation-page-cache.html We remove the Web Animation override of the deprecated method ActiveDOMObject::shouldPreventEnteringBackForwardCache_DEPRECATED() and instead ensure event dispatch is suspended along with the WebAnimation object through the adoption of a SuspendableTaskQueue. We also ensure an animation correctly suspends itself when ActiveDOMObject::suspend() and ActiveDOMObject::resume() are called. Implementing these methods showed that we have some placeholders in DeclarativeAnimation that were not necessary, so we remove those. Finally, we no longer need to track the stopped state since the SuspendableTaskQueue will close itself when ActiveDOMObject::stop() is called. * animation/DeclarativeAnimation.cpp: (WebCore::DeclarativeAnimation::stop): Deleted. (WebCore::DeclarativeAnimation::suspend): Deleted. (WebCore::DeclarativeAnimation::resume): Deleted. * animation/DeclarativeAnimation.h: * animation/WebAnimation.cpp: (WebCore::WebAnimation::WebAnimation): (WebCore::WebAnimation::enqueueAnimationPlaybackEvent): (WebCore::WebAnimation::suspend): (WebCore::WebAnimation::resume): (WebCore::WebAnimation::stop): (WebCore::WebAnimation::hasPendingActivity): (WebCore::WebAnimation::shouldPreventEnteringBackForwardCache_DEPRECATED const): Deleted. * animation/WebAnimation.h: LayoutTests: Add a new test that checks that an Animation that would run past a page's navigation is correctly suspended and resumed as it enters and leaves the back/forward cache. * webanimations/animation-page-cache-expected.txt: Added. * webanimations/animation-page-cache.html: Added. Canonical link: https://commits.webkit.org/216959@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251742 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-10-29 23:07:16 +00:00
PASS The document was destroyed
[Web Animations] Using a Web Animation leaks the Document https://bugs.webkit.org/show_bug.cgi?id=187088 <rdar://problem/41392046> Reviewed by Darin Adler. Source/WebCore: Test: webanimations/leak-document-with-web-animation.html We need to ensure that any remaining animation is cleared when the DocumentTimeline is detached from its Document. We rename WebAnimation::prepareAnimationForRemoval() to WebAnimation::remove() since it really actively disassociates the animation from its timeline. An earlier version of this patch (r233349) was rolled out due to crashes caught in the ASan configuration. The following changes were made to make it safe: - We protect the DocumentAnimationScheduler instance in displayRefreshFired() against code that might run in a requestAnimationFrame() callback that would trigger the object to be deleted. - We protect the WebAnimation instance in remove() against setEffectInternal() or setTimelineInternal() potentially causing the object to be deleted. Similar protections were addede to setEffect() and setTimeline(). - We changed ~DocumentTimeline() to a default implementation to ensure it calls ~DisplayRefreshMonitorClient() to avoid callbacks after the object has been marked for deletion. * animation/AnimationTimeline.cpp: (WebCore::AnimationTimeline::removeAnimationsForElement): We no longer need the call to removeAnimation() since the new WebAnimation::remove() method will also set the timeline to null which will eventually call removeAnimation() on the disassociated timeline. * animation/DeclarativeAnimation.cpp: (WebCore::DeclarativeAnimation::remove): (WebCore::DeclarativeAnimation::prepareAnimationForRemoval): Deleted. * animation/DeclarativeAnimation.h: * animation/DocumentAnimationScheduler.cpp: (WebCore::DocumentAnimationScheduler::displayRefreshFired): * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::detachFromDocument): Call remove() on all known animations. (WebCore::DocumentTimeline::~DocumentTimeline): Deleted. * animation/WebAnimation.cpp: (WebCore::WebAnimation::remove): Set the timeline to null to fully disassociate this animation from its timeline. (WebCore::WebAnimation::setEffect): (WebCore::WebAnimation::setEffectInternal): (WebCore::WebAnimation::setTimeline): Factor the internal timeline-association code out of this JS API method so that we can call this code without any JS-facing implications. (WebCore::WebAnimation::setTimelineInternal): (WebCore::WebAnimation::prepareAnimationForRemoval): Deleted. * animation/WebAnimation.h: LayoutTests: * webanimations/leak-document-with-web-animation-expected.txt: Added. * webanimations/leak-document-with-web-animation.html: Added. * webanimations/resources/web-animation-leak-iframe.html: Added. Canonical link: https://commits.webkit.org/202654@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@233583 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-07-06 18:31:12 +00:00
PASS successfullyParsed is true
TEST COMPLETE