Set root clip layer not to maskToBounds.

Set root clip layer not to maskToBounds.

The root layer doesn't need to clip because it's drawn to a correctly
sized surface.  The only reason it might be needed is to avoid
overlapping the scrollbars, but that's already dealt with by tree
order.  The root clip causes a lot of bugs in dynamic viewport scenarios
on Android, and it's not needed elsewhere, so disable masksToBounds
on it.  Even though it's now a no-op, we leave it in the tree structure
for consistency and because the clip bounds still contain useful
information.

Also rename "clip layer" to "container layer" since it now doesn't
necessarily clip.

NOTRY=true
BUG=259141
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=154172

[aelias_OOO_until_Jul13, 2013-07-11 00:40:45]

Hi James, I realized WebView also should not be using the root clip layer, and I
figured the cleanest solution would be to disable it unconditionally in Blink. 
After this rolls, I'll delete the CC-side code in
https://codereview.chromium.org/18647013/

[aelias_OOO_until_Jul13, 2013-07-11 00:47:22]

Adding enne@ to review list since Enne has been more involved in layer tree
structure lately.

[trchen, 2013-07-11 01:11:15]

https://codereview.chromium.org/19019004/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/19019004/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayerCompositor.cpp:2400: if (expectedAttachment !=
RootLayerAttachedViaChromeClient)
if (!isMainFrame())
sounds more straightforward IMO.

[aelias_OOO_until_Jul13, 2013-07-11 03:46:17]

https://codereview.chromium.org/19019004/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/19019004/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayerCompositor.cpp:2400: if (expectedAttachment !=
RootLayerAttachedViaChromeClient)
On 2013/07/11 01:11:16, trchen wrote:
> if (!isMainFrame())
> sounds more straightforward IMO.

Done.

[enne (OOO), 2013-07-11 17:22:10]

> Even though it's now a no-op, we leave it in the tree structure 
> for consistency and because the clip bounds still contain useful 
> information. 

Who uses that information?

I worry that some poor engineer in the future will waste their time wondering
why the clip layer doesn't clip, so I'd weakly prefer to just not create that
layer at all.

Looking at the code, I think it shouldn't be that hard to conditionally create
the clip layer.  Post-Blink fork, there are still a lot of warts in RLC that
check if the clip layer exists or not, but in Blink we always create it (and the
overflow controls host and the scroll layer).  I think these checks could just
get removed or replaced with checks for other layers.

[enne (OOO), 2013-07-11 17:26:33]

On 2013/07/11 17:22:10, enne wrote:
> > Even though it's now a no-op, we leave it in the tree structure 
> > for consistency and because the clip bounds still contain useful 
> > information. 
> 
> Who uses that information?

Answering my own question, I do see that LayerTreeImpl finds this in the tree
and uses it to reposition scrollbars and fixed pos elements due to the top
controls.  Argh, maybe the clip layer does need to stay for now, then.

lgtm

[aelias_OOO_until_Jul13, 2013-07-12 03:40:47]

OK, I renamed clipLayer to containerLayer to clarify that it may not actually
clip.

I also needed to mark NeedsRebaseline some render-surface-using layout tests. 
They have some imperceptible differences, I believe the reason is that the root
clip rect now includes the non-overlay-scrollbars and this has affects the
LayerTreeHostCommon calculations.  The remaining layout test failures will be
fixed by https://codereview.chromium.org/18202006/

[commit-bot: I haz the power, 2013-07-13 23:32:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aelias@chromium.org/19019004/21001

[commit-bot: I haz the power, 2013-07-13 23:32:45]

Change committed as 154172