RenderLayer::scrollParent should walk the containing block chain

RenderLayer::scrollParent should walk the containing block chain

Previously, we'd start out walking one step in the containing block chain and
then continue with the RenderLayer::parent chain, but that's incorrect in cases
when subsequent steps in the containing block chain jump over the scrolling
element.

R=vollick@chromium.org

[abarth-chromium, 2014-06-18 22:31:37]

This CL seems to crash inside cc.  Not sure how that's possible...

[Ian Vollick, 2014-06-19 15:55:24]

On 2014/06/18 22:31:37, abarth wrote:
> This CL seems to crash inside cc.  Not sure how that's possible...

Walking up the containing block chain lets us skip over stacking contexts. In
the test that's crashing, we get a tree like this:
scroller
  + child
      + grandchild

The containing block of both child and grandchild is the scroller, but child is
a stacking context. The result is that both child and grandchild think that
their scroll parent should be scroller, but really, grandchild should have
noticed that there was a stacking context between it and the scroller in the
stacking tree. cc cannot cope with two layers on an ancestor chain with the same
scroll parent, so we crash. I've put this patch together that keeps essentially
the same logic for RenderLayer::scrollParent but fixes the walk we do to find
the ancestor scroller (https://codereview.chromium.org/344733003/), but it's
very close to this patch. It might make more sense to merge stuff from that
patch into this one?

[abarth-chromium, 2014-06-19 16:09:53]

On 2014/06/19 at 15:55:24, vollick wrote:
> On 2014/06/18 22:31:37, abarth wrote:
> > This CL seems to crash inside cc.  Not sure how that's possible...
> 
> Walking up the containing block chain lets us skip over stacking contexts.

In that situation, how does scrolling work?  Do you scroll with your containing
block or do you scroll with your stacking context?

[Ian Vollick, 2014-06-19 16:25:33]

On 2014/06/19 16:09:53, abarth wrote:
> On 2014/06/19 at 15:55:24, vollick wrote:
> > On 2014/06/18 22:31:37, abarth wrote:
> > > This CL seems to crash inside cc.  Not sure how that's possible...
> > 
> > Walking up the containing block chain lets us skip over stacking contexts.
> 
> In that situation, how does scrolling work?  Do you scroll with your
containing
> block or do you scroll with your stacking context?

Visually, they all scroll together, so in that sense, it's not wrong that both
child and grandchild report that their scroll parent is the scroller since they
really do scroll with it. But since grandchild stacks below child, it'll get
dragged along with it so it doesn't need a scroll parent (and cc's not expecting
it to have one).

We could easily make cc able to cope with this case if you think that's a good
idea.

[abarth-chromium, 2014-06-19 16:33:20]

On 2014/06/19 at 16:25:33, vollick wrote:
> We could easily make cc able to cope with this case if you think that's a good
idea.

We can handle it in Blink.

[abarth-chromium, 2014-06-19 18:27:38]

On 2014/06/19 at 16:33:20, abarth wrote:
> On 2014/06/19 at 16:25:33, vollick wrote:
> > We could easily make cc able to cope with this case if you think that's a
good idea.
> 
> We can handle it in Blink.

OK.  I'm going to close this CL and re-work the CL that moves this computation
to CompositingInputUpdater.