REGRESSION(r152227) Images with compositing layer don't show up unless the containing window is resized.
https://bugs.webkit.org/show_bug.cgi?id=118951

Patch by Zalan Bujtas <zalan@apple.com> on 2013-07-22
Reviewed by Simon Fraser.

Ensure that the content rect is initialized when the image is set on the graphics layer.

RenderLayerBacking::updateGraphicsLayerGeometry() only updates the contents rect when
the associated graphics layer has a content layer. Since the image gets committed
on the graphics layer after the update calls, the contents rect is left uninitialized.

Source/WebCore:

Test: compositing/images/positioned-image-content-rect.html

* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateImageContents):

LayoutTests:

* compositing/images/positioned-image-content-rect-expected.html: Added.
* compositing/images/positioned-image-content-rect.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152986 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaseline the caret color test for the Mac port after r152612
https://bugs.webkit.org/show_bug.cgi?id=118961

Reviewed by Alexey Proskuryakov.

Added expected results of the caret color test for the Mac port.

* platform/mac-wk2/editing/caret/caret-color-expected.png: Added.
* platform/mac/TestExpectations:
* platform/mac/editing/caret/caret-color-expected.png: Added.
* platform/mac/editing/caret/caret-color-expected.txt: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152987 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PlugIn content can disappear after restarting
https://bugs.webkit.org/show_bug.cgi?id=118982

Reviewed by Simon Fraser.

When a snapshotted plug-in is restarted, we inserted its compositing
layer back into the tree, but didn't recalculate style. This meant
that a subsequent compositing tree operation (such as any hardware
animation) could cause the content to disappear.

* html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::setDisplayState): Force a style recalc.
(WebCore::HTMLPlugInImageElement::removeSnapshotTimerFired): Ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152989 268f45cc-cd09-0410-ab3c-d52691b4dbfc
StickyPositionContraints should not need to change to account for a RenderLayer's 
scrollOffset
https://bugs.webkit.org/show_bug.cgi?id=118958
-and corresponding-
<rdar://problem/12469203>

Reviewed by Simon Fraser.

Source/WebCore: 

Before this patch, to get sticky offsets right in overflow areas, the 
StickyPositionConstraints changed on every scroll to factor it in. This will be a 
problem once we can scroll overflow areas on the scrolling thread. The constraints 
should never have to change to account for the scroll position. This patch fixes 
that issue by changing the StickyPositionViewportConstraints’s containerBlockRect 
and stickyBoxRect to be in a coordinate space that is relative to the scrolling 
ancestor rather than being absolute. This patch also removes ‘absolute’ from those 
variable names since they are no longer absolute.

A few re-names in the StickyPositionViewportConstraints class. The parameter to 
computeStickyOffset() used to be called viewportRect, and is now called 
constrainingRect. m_absoluteStickyBoxRect is now m_stickyBoxRect, and 
m_absoluteContainingBlockRect is now m_containingBlockRect. And finally, 
layerPositionForViewportRect() is now layerPositionForConstrainingRect()
* page/scrolling/ScrollingConstraints.cpp:
(WebCore::StickyPositionViewportConstraints::computeStickyOffset):
(WebCore::StickyPositionViewportConstraints::layerPositionForConstrainingRect):
* page/scrolling/ScrollingConstraints.h:
(WebCore::StickyPositionViewportConstraints::StickyPositionViewportConstraints):
(WebCore::StickyPositionViewportConstraints::containingBlockRect):
(WebCore::StickyPositionViewportConstraints::setContainingBlockRect):
(WebCore::StickyPositionViewportConstraints::stickyBoxRect):
(WebCore::StickyPositionViewportConstraints::setStickyBoxRect):
(WebCore::StickyPositionViewportConstraints::operator==):

Accounting for the re-names. 
* page/scrolling/ScrollingStateStickyNode.cpp:
(WebCore::ScrollingStateStickyNode::syncLayerPositionForViewportRect):
(WebCore::ScrollingStateStickyNode::dumpProperties):
* page/scrolling/mac/ScrollingTreeStickyNode.mm:
(WebCore::ScrollingTreeStickyNode::parentScrollPositionDidChange):

Compute all values relative to the scrolling ancestor. This requires some juggling 
in the overflow case to factor border and padding in or out.
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::computeStickyPositionConstraints):

This is where the scrollOffset should be factored in.
(WebCore::RenderBoxModelObject::stickyPositionOffset):

LayoutTests: 

This tests stick in overflow areas where the sticky’s containing block overflows 
the overflow area. The sticky object should not extend beyond the overflow area in 
that case. 

* fast/css/sticky/sticky-top-overflow-container-overflow-expected.html: Added.
* fast/css/sticky/sticky-top-overflow-container-overflow.html: Added.



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