2020-09-17 12:39:28 +00:00
<!DOCTYPE html>
2019-11-16 17:11:44 +00:00
< meta charset = "utf-8" >
< title > Reversal of accelerated in-flight CSS Transitions< / title >
< style type = "text/css" media = "screen" >
.target.opacity {
transition: opacity 2s linear;
}
.target.opacity.in-flight {
opacity: 0;
}
.target.transform {
transition: transform 2s linear;
}
.target.transform.in-flight {
transform: scale(0);
}
< / style >
< body >
< script src = "../resources/testharness.js" > < / script >
< script src = "../resources/testharnessreport.js" > < / script >
< script >
'use strict';
function targetTest(propertyName)
{
async_test(test => {
const target = document.body.appendChild(document.createElement("div"));
target.classList.add("target");
target.classList.add(propertyName);
let initialTransition;
let reversedTransition;
// Start the initial transition.
requestAnimationFrame(() => {
target.classList.add("in-flight");
const animations = target.getAnimations();
assert_equals(animations.length, 1, "There is one animation applied to the target after starting the initial transition.");
initialTransition = animations[0];
assert_true(initialTransition instanceof CSSTransition, "There is one animation applied to the target after starting the initial transition.");
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
// Wait for the initial transition to start and then two frames before reversing the transition, to be certain that the animation did start.
// Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that very same
// frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
2019-11-16 17:11:44 +00:00
target.addEventListener("transitionstart", event => {
requestAnimationFrame(() => {
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
requestAnimationFrame(() => {
target.classList.remove("in-flight");
const animations = target.getAnimations();
assert_equals(animations.length, 1, "There is one animation applied to the target after reversing the initial transition.");
2019-11-16 17:11:44 +00:00
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
reversedTransition = animations[0];
assert_true(reversedTransition instanceof CSSTransition, "There is one animation applied to the target after reversing the initial transition.");
assert_not_equals(initialTransition, reversedTransition, "The animation applied to the target after reversing the initial transition is different than the original transition.");
2019-11-16 17:11:44 +00:00
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
target.remove();
test.done();
});
2019-11-16 17:11:44 +00:00
});
});
});
}, `A CSS transition targeting ${propertyName} can be reversed in-flight.`);
}
targetTest("opacity");
targetTest("transform");
< / script >
< / body >