haikuwebkit/LayoutTests/webanimations/css-transition-in-flight-re...

76 lines
2.9 KiB
HTML
Raw Permalink Normal View History

Remove the legacy animation code https://bugs.webkit.org/show_bug.cgi?id=216608 Reviewed by Dean Jackson. Source/WebCore: We remove the legacy animation code found in Source/WebCore/page/animation/, save for CSSPropertyAnimation which is also used by the new Web Animations engine and now moved to Source/WebCore/animation/. Since we now have a single animation engine, the runtime flags to optionally enable the Web Animations engine are not needed anymore and removed as well. We also remove some testing utilities and some RenderLayerBacking methods specific to accelerated transitions which the new animation engine does not use. * CMakeLists.txt: * Headers.cmake: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * animation/Animatable.idl: * animation/AnimationEffect.idl: * animation/AnimationPlaybackEvent.idl: * animation/AnimationPlaybackEventInit.idl: * animation/AnimationTimeline.idl: * animation/CSSAnimation.idl: * animation/CSSPropertyAnimation.cpp: Renamed from Source/WebCore/page/animation/CSSPropertyAnimation.cpp. (WebCore::PropertyWrapperVisitedAffectedColor::PropertyWrapperVisitedAffectedColor): * animation/CSSPropertyAnimation.h: Renamed from Source/WebCore/page/animation/CSSPropertyAnimation.h. * animation/CSSTransition.idl: * animation/DocumentAnimations.idl: * animation/DocumentOrShadowRootAnimations.idl: * animation/DocumentTimeline.idl: * animation/KeyframeEffect.idl: * animation/WebAnimation.idl: * animation/WebAnimationTypes.h: * css/CSSComputedStyleDeclaration.cpp: (WebCore::computeRenderStyleForProperty): * dom/Document.cpp: (WebCore::Document::resolveStyle): (WebCore::Document::didBecomeCurrentDocumentInFrame): (WebCore::Document::willBeRemovedFromFrame): (WebCore::Document::implicitClose): (WebCore::Document::resume): * dom/Element.cpp: (WebCore::Element::removedFromAncestor): * dom/PseudoElement.cpp: (WebCore::PseudoElement::clearHostElement): * history/CachedFrame.cpp: (WebCore::CachedFrame::destroy): * page/Frame.cpp: (WebCore::Frame::Frame): (WebCore::Frame::clearTimers): (WebCore::Frame::resumeActiveDOMObjectsAndAnimations): * page/Frame.h: * page/FrameView.cpp: (WebCore::FrameView::didDestroyRenderTree): (WebCore::FrameView::updateLayoutAndStyleIfNeededRecursive): * page/FrameViewLayoutContext.cpp: (WebCore::FrameViewLayoutContext::layout): * page/Page.cpp: (WebCore::Page::handleLowModePowerChange): (WebCore::Page::setIsVisibleInternal): (WebCore::Page::hiddenPageCSSAnimationSuspensionStateChanged): * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setWebAnimationsEnabled): Deleted. (WebCore::RuntimeEnabledFeatures::webAnimationsEnabled const): Deleted. (WebCore::RuntimeEnabledFeatures::setWebAnimationsCSSIntegrationEnabled): Deleted. (WebCore::RuntimeEnabledFeatures::webAnimationsCSSIntegrationEnabled const): Deleted. * page/animation/AnimationBase.cpp: Removed. * page/animation/AnimationBase.h: Removed. * page/animation/CSSAnimationController.cpp: Removed. * page/animation/CSSAnimationController.h: Removed. * page/animation/CSSAnimationControllerPrivate.h: Removed. * page/animation/CompositeAnimation.cpp: Removed. * page/animation/CompositeAnimation.h: Removed. * page/animation/ImplicitAnimation.cpp: Removed. * page/animation/ImplicitAnimation.h: Removed. * page/animation/KeyframeAnimation.cpp: Removed. * page/animation/KeyframeAnimation.h: Removed. * platform/graphics/GraphicsLayer.h: * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::isKeyframe): (WebCore::GraphicsLayerCA::createTransformAnimationsFromKeyframes): * rendering/RenderElement.cpp: (WebCore::RenderElement::animatedStyle): * rendering/RenderElement.h: (WebCore::RenderElement::startTransition): Deleted. (WebCore::RenderElement::transitionPaused): Deleted. (WebCore::RenderElement::transitionFinished): Deleted. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::currentTransform const): (WebCore::RenderLayer::calculateClipRects const): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::updateGeometry): (WebCore::RenderLayerBacking::notifyAnimationStarted): (WebCore::RenderLayerBacking::startTransition): Deleted. (WebCore::RenderLayerBacking::transitionPaused): Deleted. (WebCore::RenderLayerBacking::transitionFinished): Deleted. * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::flushPendingLayerChanges): (WebCore::RenderLayerCompositor::updateCompositingLayers): (WebCore::RenderLayerCompositor::requiresCompositingForAnimation const): (WebCore::RenderLayerCompositor::isRunningTransformAnimation const): * rendering/RenderLayerModelObject.cpp: (WebCore::RenderLayerModelObject::startTransition): Deleted. (WebCore::RenderLayerModelObject::transitionPaused): Deleted. (WebCore::RenderLayerModelObject::transitionFinished): Deleted. * rendering/RenderLayerModelObject.h: * rendering/RenderObject.h: (WebCore::RenderObject::legacyAnimation const): Deleted. * rendering/updating/RenderTreeUpdater.cpp: (WebCore::RenderTreeUpdater::tearDownRenderers): * style/StyleAdjuster.cpp: * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::createAnimatedElementUpdate): * testing/InternalSettings.cpp: (WebCore::InternalSettings::webAnimationsCSSIntegrationEnabled): Deleted. * testing/InternalSettings.h: * testing/InternalSettings.idl: * testing/Internals.cpp: (WebCore::Internals::numberOfActiveAnimations const): (WebCore::Internals::animationsAreSuspended const): (WebCore::Internals::animationsInterval const): (WebCore::Internals::suspendAnimations const): (WebCore::Internals::resumeAnimations const): (WebCore::Internals::acceleratedAnimationsForElement): (WebCore::Internals::numberOfAnimationTimelineInvalidations const): (WebCore::Internals::pauseAnimationAtTimeOnElement): Deleted. (WebCore::Internals::pauseAnimationAtTimeOnPseudoElement): Deleted. (WebCore::Internals::pauseTransitionAtTimeOnElement): Deleted. (WebCore::Internals::pauseTransitionAtTimeOnPseudoElement): Deleted. * testing/Internals.h: * testing/Internals.idl: Source/WebKit: Since we now have a single animation engine, the runtime flags to optionally enable the Web Animations engine are not needed anymore and are now removed. * Shared/WebPreferencesExperimental.yaml: * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetWebAnimationsEnabled): Deleted. (WKPreferencesGetWebAnimationsEnabled): Deleted. (WKPreferencesSetWebAnimationsCSSIntegrationEnabled): Deleted. (WKPreferencesGetWebAnimationsCSSIntegrationEnabled): Deleted. * UIProcess/API/C/WKPreferencesRefPrivate.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _setWebAnimationsCSSIntegrationEnabled:]): Deleted. (-[WKPreferences _webAnimationsCSSIntegrationEnabled]): Deleted. * UIProcess/API/Cocoa/WKPreferencesPrivate.h: * WebProcess/InjectedBundle/InjectedBundle.cpp: (WebKit::InjectedBundle::overrideBoolPreferenceForTestRunner): (WebKit::InjectedBundle::setWebAnimationsEnabled): Deleted. (WebKit::InjectedBundle::setWebAnimationsCSSIntegrationEnabled): Deleted. * WebProcess/InjectedBundle/InjectedBundle.h: Source/WebKitLegacy/mac: Since we now have a single animation engine, the runtime flags to optionally enable the Web Animations engine are not needed anymore and are now removed. * WebView/WebPreferenceKeysPrivate.h: * WebView/WebPreferences.mm: (+[WebPreferences initialize]): (-[WebPreferences webAnimationsEnabled]): Deleted. (-[WebPreferences setWebAnimationsEnabled:]): Deleted. (-[WebPreferences webAnimationsCSSIntegrationEnabled]): Deleted. (-[WebPreferences setWebAnimationsCSSIntegrationEnabled:]): Deleted. * WebView/WebPreferencesPrivate.h: * WebView/WebView.mm: (-[WebView _preferencesChanged:]): Source/WebKitLegacy/win: Since we now have a single animation engine, the runtime flags to optionally enable the Web Animations engine are not needed anymore and are now removed. * Interfaces/IWebFramePrivate.idl: * Interfaces/IWebPreferencesPrivate.idl: * WebFrame.cpp: (WebFrame::resumeAnimations): Deleted. (WebFrame::suspendAnimations): Deleted. (WebFrame::pauseAnimation): Deleted. (WebFrame::pauseTransition): Deleted. (WebFrame::numberOfActiveAnimations): Deleted. * WebFrame.h: * WebPreferenceKeysPrivate.h: * WebPreferences.cpp: (WebPreferences::initializeDefaultSettings): (WebPreferences::webAnimationsCSSIntegrationEnabled): Deleted. (WebPreferences::setWebAnimationsCSSIntegrationEnabled): Deleted. (WebPreferences::setWebAnimationsEnabled): Deleted. (WebPreferences::webAnimationsEnabled): Deleted. * WebPreferences.h: * WebView.cpp: (WebView::notifyPreferencesChanged): Tools: Since we now have a single animation engine, the runtime flags to optionally enable the Web Animations engine are not needed anymore and are now removed. * DumpRenderTree/TestOptions.cpp: (TestOptions::TestOptions): (TestOptions::webViewIsCompatibleWithOptions const): * DumpRenderTree/TestOptions.h: * DumpRenderTree/mac/DumpRenderTree.mm: (enableExperimentalFeatures): (setWebPreferencesForTestOptions): * DumpRenderTree/win/DumpRenderTree.cpp: (enableExperimentalFeatures): (setWebPreferencesForTestOptions): LayoutTests: Remove any use of now-removed testing methods and some runtime flags from layout tests. * animations/legacy-encoding-timing-function.html: * animations/resources/animation-test-helpers.js: (pauseAnimationAtTimeOnElement): * http/tests/contentextensions/css-display-none-keyframe.html: * imported/blink/transitions/resources/opacity-transform-transitions-inside-iframe-inner.html: Removed. * transitions/background-position-transitions.html: * transitions/background-transitions.html: * transitions/blendmode-transitions.html: * transitions/border-radius-transition.html: * transitions/clip-path-path-transitions.html: * transitions/clip-path-transitions.html: * transitions/clip-transition.html: * transitions/color-transition-all.html: * transitions/color-transition-premultiplied.html: * transitions/color-transition-rounding.html: * transitions/cross-fade-background-image.html: * transitions/cross-fade-border-image.html: * transitions/cubic-bezier-overflow-color.html: * transitions/cubic-bezier-overflow-length.html: * transitions/cubic-bezier-overflow-shadow.html: * transitions/cubic-bezier-overflow-svg-length.html: * transitions/cubic-bezier-overflow-transform.html: * transitions/default-timing-function.html: * transitions/delay.html: * transitions/flex-transitions.html: * transitions/font-family-during-transition.html: * transitions/frames-timing-function.html: * transitions/interrupted-all-transition.html: * transitions/longhand-vs-shorthand-initial.html: * transitions/mask-transitions.html: * transitions/min-max-width-height-transitions.html: * transitions/mismatched-shadow-styles.html: * transitions/mismatched-shadow-transitions.html: * transitions/mixed-type.html: * transitions/move-after-transition.html: * transitions/multiple-background-size-transitions.html: * transitions/multiple-background-transitions.html: * transitions/multiple-mask-transitions.html: * transitions/multiple-shadow-transitions.html: * transitions/negative-delay.html: * transitions/opacity-transition-zindex.html: * transitions/resources/transition-test-helpers.js: * transitions/shape-outside-transitions.html: * transitions/shorthand-border-transitions.html: * transitions/shorthand-transitions.html: * transitions/steps-timing-function.html: * transitions/svg-layout-transition.html: * transitions/svg-text-shadow-transition.html: * transitions/svg-transitions.html: * transitions/text-indent-transition.html: * transitions/transform-op-list-match.html: * transitions/transform-op-list-no-match.html: * transitions/transition-end-event-rendering.html: * transitions/transition-hit-test-transform.html: * transitions/transition-hit-test.html: * transitions/transition-in-delay-phase.html: * transitions/transition-on-element-with-content.html: * transitions/transition-shorthand-delay.html: * transitions/transition-timing-function.html: * transitions/transition-to-from-auto.html: * transitions/transition-to-from-undefined.html: * transitions/visited-link-color.html: * transitions/zero-duration-in-list.html: * transitions/zero-duration-with-non-zero-delay-start.html: * webanimations/accelerated-animation-interruption-display-none.html: * webanimations/accelerated-animation-removal-upon-transition-completion.html: * webanimations/accelerated-animation-suspension.html: * webanimations/accelerated-transition-by-removing-property.html: * webanimations/accessing-current-time-after-clearing-css-animation-effect.html: * webanimations/accessing-current-time-after-finished-css-animation-target-removal.html: * webanimations/css-animation-effect-target-change-and-animation-removal-crash.html: * webanimations/css-animation-effect-target-change-and-get-keyframes-crash.html: * webanimations/css-animations.html: * webanimations/css-transition-in-flight-reversal-accelerated.html: * webanimations/empty-keyframes-crash.html: * webanimations/partly-accelerated-transition-by-removing-property.html: * webanimations/setting-css-animation-none-after-clearing-effect.html: * webanimations/setting-css-animation-timing-property-via-style-after-clearing-effect.html: Canonical link: https://commits.webkit.org/229462@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@267188 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-09-17 12:39:28 +00:00
<!DOCTYPE html>
<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.
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.");
[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.");
[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();
});
});
});
});
}, `A CSS transition targeting ${propertyName} can be reversed in-flight.`);
}
targetTest("opacity");
targetTest("transform");
</script>
</body>