On investigating, we have to do the initial promotion as we don't know up front whether the positioned content will overlap later content on the page.

Looking at this simple test page: http://output.jsbin.com/segefi/1/quiet

We should be able to squash the content back into the scrolling contents layer, this requires changing the kSquashingDisallowedReasonClippingContainerMismatch check to allow the layer's clipping container to be the squashing layer and changing the kSquashingDisallowedReasonScrollsWithRespectToSquashingLayer check to also allow the same. The tricky thing is that I think we would need to create another squashing layer which is a sibling or descendant of the scrolling contents layer in order for the squashed content to move with the scroll as it should.

This seems like it may be non-trivial to introduce to CompositedLayerMapping, Chris I'd assume we would want to wait for SPv2 to do this optimization?

Also, does this mean we are unable to squash into the scrolling contents layer and we always create a layer for squashed content? Could we not in most cases squash right into the graphics layer or scrolling contents layer directly?

From chatting with Ian about why we put squashed contents into a separate layer, I believe we could remove it (i.e. squash the squashing contents layer into the graphics layer) when there were no other layers in the CompositedLayerMapping that could stack between. This could potentially remove a lot of layers - I'll file a separate bug for this.

Chris, ping, would it be reasonable to have a way to squash into the scrolling contents in the current architecture or is this another item we should block on SPv2?

Or alternately, we could change the attachment of the squashing contents layers on composited scrollers to be scrolling contents attached as I believe this would be useful more often than squashing into the scroller's graphics layer.

squashing_layer_ is separate from graphics_layer_ for technical reasons, having to
do with the need to have a different size and position, and a few other cases where
graphics_layer_ is treated specially that would need refactoring.
I'm sure it is possible to merge it, but the complexity of doing so is too much to
invest right now in SPv1.

Regarding comment 1: why can't the overlap test handle the cases where it might
overlap later content?

I investigated the test page. If the kCompositingReasonOverflowScrollingParent
trigger is turned off, then the rel-pos element still composites due to overlap.
I think we can get rid of that by changing the logic in CompositingRequirementsUpdater
to skip the overlap test if the PaintLayer's scroll ancestor is composited.

But this still leaves the question from the second paragraph above - sounds like there
are more case that would be broken?

As I mentioned in 1, we have to promote it initially because we don't the overlap information available at that time. We do later detect that it doesn't overlap but unless there was an intermediate layer created in the scroller for it to squash into we have no layer to squash into that moves with the scroll.

For example, if you add an intermediate composited layer then we squash into that layer: http://output.jsbin.com/bozuzit/quiet. We have none if you just have the scroller though because it scrolls with respect to the positioned element.