Fix repositioning of fixed elements on zooming
https://bugs.webkit.org/show_bug.cgi?id=105223

Reviewed by Beth Dakin.

Source/WebCore:

When zoomed, scrolling would move the layers of fixed-position
elements oddly. This happened because on the scrolling thread we
passed a scale of 1, rather than the actual page scale to
scrollOffsetForFixedPosition().

Fix by plumbing the page scale through the scrolling state node
to the scrolling node.

Test: platform/mac/tiled-drawing/fixed/four-bars-zoomed.html

* page/scrolling/ScrollingStateScrollingNode.cpp:
(WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode):
(WebCore::ScrollingStateScrollingNode::setFrameScaleFactor):
(WebCore::ScrollingStateScrollingNode::dumpProperties):
* page/scrolling/ScrollingStateScrollingNode.h:
(WebCore::ScrollingStateScrollingNode::frameScaleFactor):
(ScrollingStateScrollingNode):
* page/scrolling/ScrollingTreeScrollingNode.cpp:
(WebCore::ScrollingTreeScrollingNode::ScrollingTreeScrollingNode):
(WebCore::ScrollingTreeScrollingNode::update):
* page/scrolling/ScrollingTreeScrollingNode.h:
(WebCore::ScrollingTreeScrollingNode::frameScaleFactor):
(ScrollingTreeScrollingNode):
* page/scrolling/mac/ScrollingCoordinatorMac.h:
(ScrollParameters):
* page/scrolling/mac/ScrollingCoordinatorMac.mm:
(WebCore::ScrollingCoordinatorMac::frameViewLayoutUpdated):
(WebCore::ScrollingCoordinatorMac::setScrollParametersForNode):
* page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm:
(WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition):

LayoutTests:

Testcase that zoomed with fixed-position elements.

* platform/mac/tiled-drawing/fixed/four-bars-zoomed-expected.txt: Added.
* platform/mac/tiled-drawing/fixed/four-bars-zoomed.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137957 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CoordinatedGraphics] Assertion hit in WebKit::LayerTreeRenderer::setLayerState()
https://bugs.webkit.org/show_bug.cgi?id=104518

Patch by Huang Dongsung <luxtella@company100.net> on 2012-12-17
Reviewed by Noam Rosenthal.

CoordinatedGraphicsLayer::flushCompositingStateForThisLayerOnly() must perform
only during flushing pending layer changes in CoordinatedLayerTreeHost.
RenderLayerCompositor can call GraphicsLayer::flushCompositingState() regardless
of CoordinatedLayerTreeHost and it breaks our assumption. It means that
CoordinatedGraphicsLayer can send messages although m_waitingForUIProcess in
CoordinatedLayerTreeHost is true.

Assertion hits because of the same reason. If RenderLayerCompositor calls
flushCompositingState() before the first CoordinatedLayerTreeHost::flushPendingLayerChanges(),
SetCompositingLayerState message can be prior to SetRootCompositingLayer message.

We fix this by ensuring that we perform the layer flush only in the code
path originating from CoordinatedLayerTreeHost.

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::flushCompositingState):
(WebCore::CoordinatedGraphicsLayer::flushCompositingStateForThisLayerOnly):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayerClient):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:
(WebKit::CoordinatedLayerTreeHost::CoordinatedLayerTreeHost):
(WebKit::CoordinatedLayerTreeHost::flushPendingLayerChanges):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:

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