Bug 196118

Summary: [Web Animations] JS wrapper may be deleted while animation is yet to dispatch its finish event
Product: WebKit Reporter: Antoine Quint <graouts>
Component: AnimationsAssignee: Antoine Quint <graouts>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, commit-queue, dino, rniwa, sroberts, webkit-bot-watchers-bugzilla, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch for landing
none
Patch cdumez: review+

Antoine Quint
Reported 2019-03-21 16:23:15 PDT
This simple code may not work if JS garbage collection occurs while the animation is in flight: document.body.firstElementChild.animate({ marginLeft: ["0", "100px"] }, 5000).addEventListener("finish", event => console.log(event.type));
Attachments
Patch (5.47 KB, patch)
2019-03-21 16:29 PDT, Antoine Quint
no flags
Patch for landing (6.42 KB, patch)
2019-04-04 06:35 PDT, Antoine Quint
no flags
Patch (7.35 KB, patch)
2019-04-08 07:08 PDT, Antoine Quint
cdumez: review+
Antoine Quint
Comment 1 2019-03-21 16:24:18 PDT
Antoine Quint
Comment 2 2019-03-21 16:29:33 PDT
Ryosuke Niwa
Comment 3 2019-03-21 16:34:17 PDT
Comment on attachment 365643 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=365643&action=review > LayoutTests/webanimations/js-wrapper-kept-alive.html:13 > + window.myAnimation = document.getElementById("target").animate({ marginLeft: ["0px", "100px"] }, 100); Let's trigger gc() at the beginning of the test to start with a clean state. Also, can't we just declare a local variable and call gc() outside runTest()? > LayoutTests/webanimations/js-wrapper-kept-alive.html:18 > + window.myAnimation.addEventListener("finish", event => { > + shouldBeTrue("event.target._isMyAnimation"); > + finishJSTest(); > + }); Instead of making this test timeout, can we use setTimeout to check whether this event listener had fired? e.g. window.sawEvent = false; myAnimation.addEventListener("finish", (event) => { window.sawEvent = true; shouldBeTrue(event.target._isMyAnimation); }); setTimeout(() => shouldBeTrue('sawEvent'), 0)
Antoine Quint
Comment 4 2019-03-21 16:52:51 PDT
(In reply to Ryosuke Niwa from comment #3) > Comment on attachment 365643 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=365643&action=review > > > LayoutTests/webanimations/js-wrapper-kept-alive.html:13 > > + window.myAnimation = document.getElementById("target").animate({ marginLeft: ["0px", "100px"] }, 100); > > Let's trigger gc() at the beginning of the test to start with a clean state. Sure. > Also, can't we just declare a local variable and call gc() outside runTest()? Sure. > > LayoutTests/webanimations/js-wrapper-kept-alive.html:18 > > + window.myAnimation.addEventListener("finish", event => { > > + shouldBeTrue("event.target._isMyAnimation"); > > + finishJSTest(); > > + }); > > Instead of making this test timeout, can we use setTimeout to check whether > this event listener had fired? We can use another longer-running animation as a form of timeout, which allows us not to use some arbitrary value since the animation could legitimately take a long time to start and complete depending on system load.
Antoine Quint
Comment 5 2019-03-21 16:54:04 PDT
Shawn Roberts
Comment 6 2019-03-22 13:57:10 PDT
Since this revision. the following test is timing out consistently. legacy-animation-engine/animations/resume-after-page-cache.html Flakiness Dashboard : https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=animations%2Fresume-after-page-cache.html Reproduced with : run-webkit-tests legacy-animation-engine/animations/resume-after-page-cache.html --iterations 50 --exit-after-n-failures=5 --no-retry Timed out 100% of the time locally with r243346, passes with r243345 Reproduced with iOS Simulator Release and Debug. Mac WK1 and WK2
Shawn Roberts
Comment 7 2019-03-27 13:32:17 PDT
rolled out in https://trac.webkit.org/changeset/243561/webkit Was causing timeouts on bots consistently across 10 queues.
Shawn Roberts
Comment 8 2019-03-27 13:41:46 PDT
Reopening bug.
Antoine Quint
Comment 9 2019-04-04 06:35:39 PDT
Created attachment 366708 [details] Patch for landing
WebKit Commit Bot
Comment 10 2019-04-04 07:16:11 PDT
Comment on attachment 366708 [details] Patch for landing Clearing flags on attachment: 366708 Committed r243868: <https://trac.webkit.org/changeset/243868>
WebKit Commit Bot
Comment 11 2019-04-04 07:16:12 PDT
All reviewed patches have been landed. Closing bug.
Shawn Roberts
Comment 12 2019-04-04 15:32:44 PDT
Hi Antoine, It appears the same timeout is occurring with animations/resume-after-page-cache.html after https://trac.webkit.org/changeset/243868/webkit Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=animations%2Fresume-after-page-cache.html Reproduced with: run-webkit-tests animations/resume-after-page-cache.html --iterations 25 -f --force Test will pass 3 times and failed unexpectedly (test timed out, text diff). Test was skipped awhile ago for flaky failures, but the timeout happens after r243868, does not occur with previous revisions.
Shawn Roberts
Comment 13 2019-04-04 16:14:55 PDT
Reverted r243868 for reason: Causing timeouts failures on several queues Committed r243917: <https://trac.webkit.org/changeset/243917>
Antoine Quint
Comment 14 2019-04-08 07:08:27 PDT
Chris Dumez
Comment 15 2019-04-08 08:47:47 PDT
Comment on attachment 366933 [details] Patch Yes, this seems fine.
Antoine Quint
Comment 16 2019-04-08 11:49:12 PDT
Note You need to log in before you can comment on or make changes to this bug.