Avoid requiring a recalc to update compositing state for iframes

Source/core/rendering/RenderLayerCompositor.cpp

Index: Source/core/rendering/RenderLayerCompositor.cpp
diff --git a/Source/core/rendering/RenderLayerCompositor.cpp b/Source/core/rendering/RenderLayerCompositor.cpp
index 4f5bddd0b58b1476df688a0ba7b82845c579c52c..542c4c499e3794f07c1155fbc9388d6e8527843c 100644
--- a/Source/core/rendering/RenderLayerCompositor.cpp
+++ b/Source/core/rendering/RenderLayerCompositor.cpp
@@ -2468,8 +2468,10 @@ void RenderLayerCompositor::notifyIFramesOfCompositingChange()
 
     // Compositing also affects the answer to RenderIFrame::requiresAcceleratedCompositing(), so
     // we need to schedule a style recalc in our parent document.
-    if (HTMLFrameOwnerElement* ownerElement = m_renderView->document().ownerElement())
+    if (HTMLFrameOwnerElement* ownerElement = m_renderView->document().ownerElement()) {
+        ownerElement->document().renderView()->compositor()->setNeedsToRecomputeCompositingRequirements();
         ownerElement->scheduleLayerUpdate();
+    }

[abarth-chromium, 2014/02/06 03:27:50]

I ran into this same function when working on putting the layout states into the
DocumentLifecycle state machine:

https://codereview.chromium.org/156413002

The problem with this function is that it schedules a style recalc while layout
is on the stack.  Now that we're more careful to only do layout when we're about
to put up a frame, the style recalc doesn't actually happen until the next
frame.  I'm not sure whether that's the cause of the bug you're seeing, but it's
one way that we might put up a frame while we're in an inconsistent state.

[dstockwell, 2014/02/06 03:36:19]

I think that's the main reason this is broken at head. I believe with these
changes it should be possible to remove the recalc request here.

 }
 
 bool RenderLayerCompositor::layerHas3DContent(const RenderLayer* layer) const