Removing a RenderLayer's CLM should trigger a repaint

Source/core/rendering/compositing/RenderLayerCompositor.cpp

Index: Source/core/rendering/compositing/RenderLayerCompositor.cpp
diff --git a/Source/core/rendering/compositing/RenderLayerCompositor.cpp b/Source/core/rendering/compositing/RenderLayerCompositor.cpp
index 81603f801f981f1f2d05c5322fefc8b5cb3b13c7..2fc48f0fb155b8b2a3f821f895cd1eec39154015 100644
--- a/Source/core/rendering/compositing/RenderLayerCompositor.cpp
+++ b/Source/core/rendering/compositing/RenderLayerCompositor.cpp
@@ -432,6 +432,9 @@ bool RenderLayerCompositor::allocateOrClearCompositedLayerMapping(RenderLayer* l
 
             layer->clearCompositedLayerMapping();
             compositedLayerMappingChanged = true;
+
+            // If we need to repaint, do so now that we've removed the compositedLayerMapping.
+            repaintOnCompositingChange(layer);

[Ian Vollick, 2014/06/12 20:17:10]

This is interesting. When compositedLayerMappingChanged is set to true, the
CompositingLayerAssign adds it to a list of layers to repaint later on. Is it
somehow invalid to be issuing deferred repaints?

[ajuma, 2014/06/12 20:33:50]

The call to allocateOrClearCompositedLayerMapping made in
applyUpdateLayerCompositingStateChickenEggHacks ignores the returned value (that
is, the value of compositedLayerMappingChanged). Issuing a repaint there when
the returned value is true fixes the bug too.

[Ian Vollick, 2014/06/12 20:37:07]

Ah, right! I think that's far preferable to issuing the repaint here. Not only
will that let us defer repaints correctly on the awesome-RLC-codepath, it'll
ensure that it's removed when the hacks go away.

[chrishtr, 2014/06/12 20:37:29]

Please do it there instead. That way it's contained to the chicken-egg hack
case.

[ajuma, 2014/06/12 21:08:00]

Done.

         }
 
         break;