Layer squashing causes incorrect rendering while scrolling in Gmail

Source/core/rendering/RenderLayer.cpp

Index: Source/core/rendering/RenderLayer.cpp
diff --git a/Source/core/rendering/RenderLayer.cpp b/Source/core/rendering/RenderLayer.cpp
index 953e0e3d8e56eb3683396918b6b09c4bc959aba2..2a6ca0e8107783f77ce5509be5b7cc8b77d2628e 100644
--- a/Source/core/rendering/RenderLayer.cpp
+++ b/Source/core/rendering/RenderLayer.cpp
@@ -3429,7 +3429,7 @@ LayoutRect RenderLayer::boundingBoxForCompositing(const RenderLayer* ancestorLay
 
     RenderLayerStackingNodeIterator iterator(*m_stackingNode.get(), AllChildren);
     while (RenderLayerStackingNode* node = iterator.next()) {
-        if (node->layer()->hasCompositedLayerMapping() && options != ApplyBoundsChickenEggHacks)
+        if (options != ApplyBoundsChickenEggHacks && node->layer()->compositingState() != NotComposited)

[Ian Vollick, 2014/05/08 14:40:11]

I was worried that if node->layer() was squashing, that it might be squashing
into us. I don't think that will ever happen (argument to follow*), but even if
it did, Adam pointed out offline that it wouldn't matter: the bounds we're
computing here are distinct from the bounds of CLM::m_squashingLayer whose
bounds are calculated elsewhere (in CLM::updateSquashingLayerGeometry).

* We only squash layers that a) overlap, b) are assumed to overlap, or c) have a
"scroll parent".

For the overlap cases, if we were to try and squash the two layers it would mean
that they both overlap (or are assumed to overlap) some composited content. But
if one layer was a descendant of the other, the child should have painted into
the parent naturally and shouldn't have been separately promoted/squashed. So
this situation should never happen.

For the scroll parent case, it's also impossible. A layer has a scroll parent if
its scrolling ancestor is not actually an ancestor in the composited layer tree.
And only the root of the composited subtree that scrolls with this non-ancestor
gets assigned a scroll parent (the descendants get taken along for the right).
It's also worth noting that we only squash layers that scroll together
(otherwise we'd have to repaint every time they moved). So if we're trying to
squash a layer with a scroll parent into us, it means that that we've both
decided to be composited, and that we scroll together. If that were true, we
should be the one with the scroll parent pointer!

So, given the above, it might make sense to add a sanity-check ASSERT here to
document our assumptions, or at the very least a comment.

             continue;
         result.unite(node->layer()->boundingBoxForCompositing(this, options));
     }