Bug 211232 – [Web Animations] imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is a flaky failure

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Antoine Quint]

https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fweb-animations%2Ftiming-model%2Ftimelines%2Fupdate-and-send-events.html

https://build.webkit.org/results/Apple%20Mojave%20Debug%20WK1%20(Tests)/r260898%20(10517)/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-pretty-diff.html:

--- /Volumes/Data/slave/mojave-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt
+++ /Volumes/Data/slave/mojave-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-actual.txt
@@ -6,5 +6,5 @@
 PASS Queues a cancel event in transitionstart event callback 
 PASS Sorts events for the same transition 
 PASS Playback events with the same timeline retain the order in which they arequeued 
-PASS All timelines are updated before running microtasks 
+FAIL All timelines are updated before running microtasks promise_test: Unhandled rejection with value: object "AbortError: The operation was aborted."

[Radar WebKit Bug Importer]

<rdar://problem/62650227>

[Antoine Quint]

This reproduces locally with this command:

rwt --release imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html --iterations=1000 --exit-after-n-failures=1

Eventually the test will fail.

[Antoine Quint]

There's some funky code in DocumentTimeline::currentTime() which leads to slightly different timing for two DocumentTimelines. I think we want to move the notion of the cached current time up to DocumentTimelinesController, or maybe just removing this block of code will work:

    auto& mainDocumentTimeline = m_document->timeline();
    if (&mainDocumentTimeline != this) {
        if (auto mainDocumentTimelineCurrentTime = mainDocumentTimeline.currentTime())
            return *mainDocumentTimelineCurrentTime - m_originTime;
        return WTF::nullopt;
    }

[Antoine Quint]

Created attachment 398775 [details]
Patch

[Dean Jackson]

Comment on attachment 398775 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=398775&action=review

> Source/WebCore/ChangeLog:17
> +        It would sometime happen that animA in one frame and animB in another, when they should always finished in sync. Thus animA.finished would
> +        resolve and animB.cancel() would be called, rejecting animB.finished. This happened because animB was attached to a DocumentTimeline created
> +        by script which isn't the main DocumenTimeline accessed via document.timeline. Some curious code would handle syncing of the various timelines
> +        such that they would use a shared timebase. This was in DocumentTimeline::currentTime():

Sometimes, animA and animB would finish in different frames even though they were designed to finish at the same time. If this happened, animA.finished would resolve and trigger animB.cancel, which then rejected animB.finished.

> Source/WebCore/ChangeLog:28
> +        We now move the currentTime caching at the DocumentTimelinesController level which ensures all DocumentTimeline objects attached to a given
> +        Document use the exact same currentTime(). This prompted some overdue refactoring where also all the related animation suspension code is moved
> +        from DocumentTimeline up to DocumentTimelinesController.

Again, I don't understand how you manage to have such a large value for your line wrapping mark :)

View -> Edit -> Wrap Column

[Antoine Quint]

Committed r261336: <https://trac.webkit.org/changeset/261336>