Layer squashing causes incorrect rendering while scrolling in Gmail

Source/core/rendering/RenderLayer.cpp

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012 Apple Inc. All rights reserved.
  *
  * Portions are Copyright (C) 1998 Netscape Communications Corporation.
  *
  * Other contributors:
  *   Robert O'Callahan <roc+@cs.cmu.edu>
  *   David Baron <dbaron@fas.harvard.edu>
  *   Christian Biesinger <cbiesinger@web.de>
  *   Randall Jesup <rjesup@wgate.com>
@@ skipping 3411 matching lines @@
         result.unite(m_reflectionInfo->reflectionLayer()->boundingBoxForCompositing(this));
 
     ASSERT(m_stackingNode->isStackingContainer() || !m_stackingNode->hasPositiveZOrderList());
 
 #if !ASSERT_DISABLED
     LayerListMutationDetector mutationChecker(const_cast<RenderLayer*>(this)->stackingNode());
 #endif
 
     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));
     }
 
     // FIXME: We can optimize the size of the composited layers, by not enlarging
     // filtered areas with the outsets if we know that the filter is going to render in hardware.
     // https://bugs.webkit.org/show_bug.cgi?id=81239
     m_renderer->style()->filterOutsets().expandRect(result);
 
     if (shouldIncludeTransform)
@@ skipping 573 matching lines @@
     }
 }
 
 void showLayerTree(const WebCore::RenderObject* renderer)
 {
     if (!renderer)
         return;
     showLayerTree(renderer->enclosingLayer());
 }
 #endif