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

53 lines
1.8 KiB
HTML
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
<!DOCTYPE html>
<html>
<body onload="runTest()">
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
<script src="../resources/js-test.js"></script>
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
<script src="../resources/gc.js"></script>
[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
<script>
description("This test asserts that Document doesn't leak when a Web Animation is created.");
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
if (window.internals) {
[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
jsTestIsAsync = true;
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
window.onload = function () {
testDocumentIsNotLeaked(
async function initAndRemove(frameCount)
{
let frames = await new Promise((resolve, reject) => {
let frames = [];
let counter = 0;
function onLoad() {
counter++;
if (counter == frameCount)
resolve(frames);
}
for (let i = 0; i < frameCount; ++i) {
let frame = document.createElement('iframe');
frame.src = "resources/web-animation-leak-iframe.html";
frame.onload = onLoad;
document.body.appendChild(frame);
frames.push(frame);
}
});
debug("The iframe has finished loading.");
let frameIdentifiers = [];
for (let i = 0; i < frameCount; ++i) {
let frame = frames[i];
frameIdentifiers.push(internals.documentIdentifier(frame.contentDocument));
frame.remove();
}
nukeArray(frames);
frames = null;
return frameIdentifiers;
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
}
Code pattern in GC tests in LayoutTests is broken https://bugs.webkit.org/show_bug.cgi?id=211595 Reviewed by Saam Barati. LayoutTests have several tests which attempt to ensure that document is not leaked. But they are broken since these tests are not correctly handling conservative GC of JavaScriptCore. These tests are taking a following approach. 1. Allocate *one* iframe doing something inside it. 2. Remove iframe from the parent document to make it released. 3. Repeatedly invoke GC and test whether (1)'s document gets collected. This is not the right approach. Since JavaScriptCore has conservative GC, it is easily possible that (1)'s pointer value remains in some of conservative roots: CPU registers, stack etc. And JavaScriptCore conservative GC scans it and keeps it alive. The above approach makes the test super flaky and any unrelated changes in JavaScriptCore and C compiler can make this test failed. This is not a problem in practice. Web pages are executing various kind of code and they clobber conservative roots. However, tests in LayoutTests are too simple to keep it alive accidentally. The right approach for conservative GC is the following. 1. Allocate *many* iframes doing something inside them with loop. By creating iframes with loop, for every iteration, it is likely that the same CPU registers and stack locations are overwritten by the last created iframe reference. This dramatically reduces the possibility for GC to find these addresses in conservative roots. 2. Remove iframes from the parent document to make them released. 3. Repeatedly invoke GC and test whether *one of (1) iframes* gets collected at least. Theoretically this is still possible that completely unrelated integer value in conservative roots can point to the reference of (1). By allocating many iframes in (1) and testing one of them, we can reduce the possibility of this conflict. This patch adds testDocumentIsNotLeaked helper function to enforce this pattern. And rewrite broken tests with this helper to make it less-flaky. * highlight/highlight-world-leak.html: * http/tests/IndexedDB/collect-IDB-objects.https.html: * http/tests/media/clearkey/collect-webkit-media-session.html: * http/tests/media/media-stream/collect-media-devices.https.html: * http/tests/resources/gc.js: Added. (window.gc.gcRec): (window.gc.window.gc): (nukeArray): (async testDocumentIsNotLeaked): * intersection-observer/no-document-leak.html: * performance-api/performance-observer-no-document-leak.html: * resources/gc.js: (nukeArray): (async testDocumentIsNotLeaked): * webanimations/leak-document-with-web-animation.html: Canonical link: https://commits.webkit.org/224541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@261391 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-05-08 17:14:15 +00:00
).then(
() => testPassed("The document was destroyed"),
(error) => testFailed(error.message)
).finally(finishJSTest);
};
[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
}
</script>
</body>
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
</html>