haikuwebkit/LayoutTests/transitions/created-while-suspended-exp...

13 lines
520 B
Plaintext
Raw Permalink Normal View History

Allow new transitions to run even when controller is suspended https://bugs.webkit.org/show_bug.cgi?id=119171 <rdar://problem/14511404> Reviewed by Simon Fraser. Source/WebCore: Expose a new property on AnimationController that allows newly created animations to run even if the controller says it is suspended. See WebKit ChangeLog for more details. Test: transitions/created-while-suspended.html * WebCore.exp.in: Export the new methods so WebView can use them. * page/animation/AnimationController.cpp: (WebCore::AnimationControllerPrivate::AnimationControllerPrivate): Initialize new flag to false. (WebCore::AnimationControllerPrivate::startAnimationsIfNotSuspended): Check new flag is not true. (WebCore::AnimationControllerPrivate::setAllowsNewAnimationsWhileSuspended): Expose setter. (WebCore::AnimationController::allowsNewAnimationsWhileSuspended): "Public" getter. (WebCore::AnimationController::setAllowsNewAnimationsWhileSuspended): "Public" setter. * page/animation/AnimationController.h: * page/animation/AnimationControllerPrivate.h: (WebCore::AnimationControllerPrivate::allowsNewAnimationsWhileSuspended): * page/animation/CompositeAnimation.cpp: (WebCore::CompositeAnimation::CompositeAnimation): Only suspend if new flag is false. Everything else relies on the m_suspended flag, so the real code change is this one line. Source/WebKit/mac: Expose a new SPI on WebView that triggers the (buggy) old behaviour for animations, such that any newly created animations will start even when the document is supposedly suspended. It turns out that client content was unknowingly relying on this behaviour - e.g. suspending a view, loading a bunch of new content, bringing the view on screen and then unsuspending. In this situation, we were not running CSS transitions, because the page was suspended. However, JS was still triggering them, and content was expecting a transitionEnd event. * WebView/WebView.mm: (-[WebView allowsNewCSSAnimationsWhileSuspended]): Calls into AnimationController. (-[WebView setAllowsNewCSSAnimationsWhileSuspended:]): Ditto. * WebView/WebViewPrivate.h: New methods listed above. LayoutTests: This is actually a test to make sure this fix didn't break anything. There is no way to trigger the new behaviour from the test system (or from Safari). Canonical link: https://commits.webkit.org/137171@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153396 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-27 00:57:31 +00:00
This test creates a box, adds a transition, then sets the left property. It will only have reproducible output when run in the test system
*** Starting test.
Transitions should not be suspended: PASS
*** Suspending Animations/Transitions
Transitions should be suspended: PASS
*** Creating the box.
*** Adding transition property and setting left to 100px. We should NOT see transition events.
*** Resuming Animations/Transitions
Transitions should not be suspended: PASS
PASS: Transition ended on element with id: box
Allow new transitions to run even when controller is suspended https://bugs.webkit.org/show_bug.cgi?id=119171 <rdar://problem/14511404> Reviewed by Simon Fraser. Source/WebCore: Expose a new property on AnimationController that allows newly created animations to run even if the controller says it is suspended. See WebKit ChangeLog for more details. Test: transitions/created-while-suspended.html * WebCore.exp.in: Export the new methods so WebView can use them. * page/animation/AnimationController.cpp: (WebCore::AnimationControllerPrivate::AnimationControllerPrivate): Initialize new flag to false. (WebCore::AnimationControllerPrivate::startAnimationsIfNotSuspended): Check new flag is not true. (WebCore::AnimationControllerPrivate::setAllowsNewAnimationsWhileSuspended): Expose setter. (WebCore::AnimationController::allowsNewAnimationsWhileSuspended): "Public" getter. (WebCore::AnimationController::setAllowsNewAnimationsWhileSuspended): "Public" setter. * page/animation/AnimationController.h: * page/animation/AnimationControllerPrivate.h: (WebCore::AnimationControllerPrivate::allowsNewAnimationsWhileSuspended): * page/animation/CompositeAnimation.cpp: (WebCore::CompositeAnimation::CompositeAnimation): Only suspend if new flag is false. Everything else relies on the m_suspended flag, so the real code change is this one line. Source/WebKit/mac: Expose a new SPI on WebView that triggers the (buggy) old behaviour for animations, such that any newly created animations will start even when the document is supposedly suspended. It turns out that client content was unknowingly relying on this behaviour - e.g. suspending a view, loading a bunch of new content, bringing the view on screen and then unsuspending. In this situation, we were not running CSS transitions, because the page was suspended. However, JS was still triggering them, and content was expecting a transitionEnd event. * WebView/WebView.mm: (-[WebView allowsNewCSSAnimationsWhileSuspended]): Calls into AnimationController. (-[WebView setAllowsNewCSSAnimationsWhileSuspended:]): Ditto. * WebView/WebViewPrivate.h: New methods listed above. LayoutTests: This is actually a test to make sure this fix didn't break anything. There is no way to trigger the new behaviour from the test system (or from Safari). Canonical link: https://commits.webkit.org/137171@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153396 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-27 00:57:31 +00:00