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).

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153396 268f45cc-cd09-0410-ab3c-d52691b4dbfc
With frame flattening on, too many resize events fired if document is resized in onresize handler.
https://bugs.webkit.org/show_bug.cgi?id=119075

Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2013-07-26
Reviewed by Simon Fraser.

With http://trac.webkit.org/changeset/149287, WebCore also sends resize event in FrameView::setFrameRect.  When
flattening an iframe, setFrameRect could be called multiple times from RenderFrameBase::layoutWithFlattening and
we could get multiple resize events.  This patch adds a flag in FrameView to disallow sending resize events if
we are inside layoutWithFlattening.  The resize event will be sent in performPostLayoutTasks after the iframe
is done laying out.

Manually tested by verifying the rendering slowness in www.hi-pda.com is fixed when frame flattening is enabled.

* page/FrameView.cpp:
(WebCore::FrameView::FrameView):
(WebCore::FrameView::setFrameRect):
* page/FrameView.h:
(WebCore::FrameView::setResizeEventAllowed):
(WebCore::FrameView::resizeEventAllowed):
* rendering/RenderFrameBase.cpp:
(WebCore::RenderFrameBase::layoutWithFlattening):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153397 268f45cc-cd09-0410-ab3c-d52691b4dbfc