Clip scrollbars to box bounds when they don't fit.

Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::attachFrameContentLayersToIframeLayer must preserve
overflow controls just like the "!parented" path of GraphicsLayerTreeBuilder.

BUG=549174
Committed: https://crrev.com/bf0a5ac073c0844a514a979beab5c8b08a445393
Cr-Commit-Position: refs/heads/master@{#360860}

Committed: https://crrev.com/74aa5e43fc22ffaa2538dca20aa36e22a3e9df38
Cr-Commit-Position: refs/heads/master@{#361037}

[skobes, 2015-11-17 06:35:21]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

BUG=549174
==========

[skobes, 2015-11-17 06:36:56]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

BUG=549174
==========

[skobes, 2015-11-18 01:48:09]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::update.

BUG=549174
==========

[skobes, 2015-11-18 03:55:50]

skobes@chromium.org changed reviewers:
+ chrishtr@chromium.org, vollick@chromium.org

[skobes, 2015-11-18 04:00:31]

Patchset #1 (id:1) has been deleted

[skobes, 2015-11-18 04:00:41]

Patchset #1 (id:20001) has been deleted

[skobes, 2015-11-18 04:00:49]

Patchset #1 (id:40001) has been deleted

[skobes, 2015-11-18 04:00:58]

Patchset #1 (id:60001) has been deleted

[skobes, 2015-11-18 04:02:45]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::update.

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::rebuild.

BUG=549174
==========

[Ian Vollick, 2015-11-18 13:41:05]

core/layout/compositing/* looks great to me. I defer to Chris for paint/

I know it's a pain, but could you please upload the new baselines for one
platform so that we can confirm they're sane?

https://codereview.chromium.org/1448253002/diff/80001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(right):

https://codereview.chromium.org/1448253002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:860:
IntSize offsetFromLayoutObject = m_graphicsLayer->offsetFromLayoutObject() -
roundedIntSize(m_owningLayer.subpixelAccumulation());
Ah, this is so much nicer!

[skobes, 2015-11-19 00:11:30]

On 2015/11/18 13:41:05, vollick wrote:
> I know it's a pain, but could you please upload the new baselines for one
> platform so that we can confirm they're sane?

Done.

Most of the rebaselines are tests that dump internals.layerTreeAsText, so the
output has "bounds": [w, h] reflecting the new clip on
m_overflowControlsHostLayer.

In a few cases, the overflow controls host layer did not previously exist.  This
reflects the change in GraphicsLayerTreeBuilder::rebuild to preserve it when
parentForSublayers() would return m_graphicsLayer.

The selection gap tests have slightly taller document layers, because the output
of internals.layerTreeAsText (which now has more lines in it) is rendered as
content instead of raw text.

The new image for width100percent-textarea.html shows the expected cropping of
scrollbars in narrow textareas.

[Ian Vollick, 2015-11-19 00:43:16]

On 2015/11/19 00:11:30, skobes wrote:
> On 2015/11/18 13:41:05, vollick wrote:
> > I know it's a pain, but could you please upload the new baselines for one
> > platform so that we can confirm they're sane?
> 
> Done.
> 
> Most of the rebaselines are tests that dump internals.layerTreeAsText, so the
> output has "bounds": [w, h] reflecting the new clip on
> m_overflowControlsHostLayer.
> 
> In a few cases, the overflow controls host layer did not previously exist. 
This
> reflects the change in GraphicsLayerTreeBuilder::rebuild to preserve it when
> parentForSublayers() would return m_graphicsLayer.
> 
> The selection gap tests have slightly taller document layers, because the
output
> of internals.layerTreeAsText (which now has more lines in it) is rendered as
> content instead of raw text.
> 
> The new image for width100percent-textarea.html shows the expected cropping of
> scrollbars in narrow textareas.

Thank you very much for doing that. Agree that the new baselines are acceptable.

lgtm % christr

[chrishtr, 2015-11-19 17:29:52]

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(left):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:1366:
layer->setPosition(hBar->frameRect().location() - offsetFromLayoutObject);
subpixelAccumulation was incorrectly omitted before?

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(right):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:860:
IntSize offsetFromLayoutObject = m_graphicsLayer->offsetFromLayoutObject() -
roundedIntSize(m_owningLayer.subpixelAccumulation());
Add comments explaining what this is doing and why this is the correct formula.

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BlockPainter.cpp (right):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BlockPainter.cpp:77: BoxClipper
boxClipper(m_layoutBlock, paintInfo, paintOffset, ClipForScrollbars);
Your use of BoxClipper is not quite right. For example, it does not emit a
unique display item id.

In your use case, if line 77 here has been reached, then we should always clip
right? If so, just using a ClipRecorder with a new display item id and
borderBoxRect is a lot simpler.

https://codereview.chromium.org/1448253002/diff/140001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp
(left):

https://codereview.chromium.org/1448253002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:108:
if (!currentCompositedLayerMapping->hasClippingLayer() &&
!currentCompositedLayerMapping->hasScrollingLayer()) {
Where has this logic gone?

[skobes, 2015-11-19 18:30:08]

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(left):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:1366:
layer->setPosition(hBar->frameRect().location() - offsetFromLayoutObject);
On 2015/11/19 17:29:52, chrishtr wrote:
> subpixelAccumulation was incorrectly omitted before?

No, what I have done is to move this offset out of the individual scrollbar
layers and into the positioning of their parent in
updateOverflowControlsHostLayerGeometry.  There should be no change in behavior
with respect to subpixel accumulation.

Though I admit that I do not really understand the role of
PaintLayer::subpixelAccumulation() in this computation.

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(right):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:860:
IntSize offsetFromLayoutObject = m_graphicsLayer->offsetFromLayoutObject() -
roundedIntSize(m_owningLayer.subpixelAccumulation());
On 2015/11/19 17:29:52, chrishtr wrote:
> Add comments explaining what this is doing and why this is the correct
formula.

Done.

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BlockPainter.cpp (right):

https://codereview.chromium.org/1448253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BlockPainter.cpp:77: BoxClipper
boxClipper(m_layoutBlock, paintInfo, paintOffset, ClipForScrollbars);
On 2015/11/19 17:29:52, chrishtr wrote:
> Your use of BoxClipper is not quite right. For example, it does not emit a
> unique display item id.
> 
> In your use case, if line 77 here has been reached, then we should always clip
> right? If so, just using a ClipRecorder with a new display item id and
> borderBoxRect is a lot simpler.

Done.

https://codereview.chromium.org/1448253002/diff/140001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp
(left):

https://codereview.chromium.org/1448253002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:108:
if (!currentCompositedLayerMapping->hasClippingLayer() &&
!currentCompositedLayerMapping->hasScrollingLayer()) {
On 2015/11/19 17:29:52, chrishtr wrote:
> Where has this logic gone?

This code was restoring the overflow controls in the case where they were
disconnected from the tree by parentForSublayers()->setChildren or by
parentFrameContentLayers.  But it did so by separating them from
m_overflowControlsHostLayer, which is no longer safe.

The overflow controls are now restored by CompositedLayerMapping::setSublayers,
which keeps them under m_overflowControlsHostLayer.

[skobes, 2015-11-19 21:33:46]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the changes in BlockPainter
and BoxClipper.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::rebuild.

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::rebuild.

BUG=549174
==========

[chrishtr, 2015-11-20 01:20:43]

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp
(right):

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:100:
parented =
PaintLayerCompositor::parentFrameContentLayers(toLayoutPart(layer.layoutObject()));
So you figured out what this function does? Could you rename it to some thing
clearer and
remove the FIXME next to its definition?

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:103:
currentCompositedLayerMapping->setSublayers(layerChildren);
How does this restore the various graphics layers that used to be handled in
lines 105-123? IOW why is layerChildren the right set of layers? A little
confused by that.

[skobes, 2015-11-20 01:35:01]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::parentFrameContentLayers must preserve overflow controls
just like the "!parented" path of GraphicsLayerTreeBuilder::rebuild.

BUG=549174
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::attachFrameContentLayersToIframeLayer must preserve
overflow controls just like the "!parented" path of GraphicsLayerTreeBuilder.

BUG=549174
==========

[skobes, 2015-11-20 01:35:21]

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp
(right):

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:100:
parented =
PaintLayerCompositor::parentFrameContentLayers(toLayoutPart(layer.layoutObject()));
On 2015/11/20 01:20:42, chrishtr wrote:
> So you figured out what this function does? Could you rename it to some thing
> clearer and
> remove the FIXME next to its definition?

Done.

(It's less confusing when you realize "parent" was meant as a verb.)

https://codereview.chromium.org/1448253002/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/GraphicsLayerTreeBuilder.cpp:103:
currentCompositedLayerMapping->setSublayers(layerChildren);
On 2015/11/20 01:20:42, chrishtr wrote:
> How does this restore the various graphics layers that used to be handled in
> lines 105-123? IOW why is layerChildren the right set of layers? A little
> confused by that.

They aren't in layerChildren.  The relevant code is inside
CompositedLayerMapping::setSublayers:

    // If we have scrollbars, but are not using composited scrolling, then
parentForSublayers may return m_graphicsLayer.
    // In that case, the above call to setChildren has clobbered the overflow
controls host layer, so we need to reattach it.
    if (needsOverflowControlsReattached)
        parent->addChild(overflowControlsContainer);

The "various graphics layers" you refer to are the children of
overflowControlsContainer.

[chrishtr, 2015-11-20 18:02:53]

The CQ bit was checked by chrishtr@chromium.org

[chrishtr, 2015-11-20 18:02:54]

lgtm

[chrishtr, 2015-11-20 18:02:54]

The patchset sent to the CQ was uploaded after l-g-t-m from vollick@chromium.org
Link to the patchset: https://codereview.chromium.org/1448253002/#ps180001
(title: "rename parentFrameContentLayers")

[commit-bot: I haz the power, 2015-11-20 18:05:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1448253002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1448253002/180001

[commit-bot: I haz the power, 2015-11-20 18:13:09]

Committed patchset #6 (id:180001)

[commit-bot: I haz the power, 2015-11-20 18:14:51]

Patchset 6 (id:??) landed as
https://crrev.com/bf0a5ac073c0844a514a979beab5c8b08a445393
Cr-Commit-Position: refs/heads/master@{#360860}

[grt (UTC plus 2), 2015-11-20 20:53:34]

A revert of this CL (patchset #6 id:180001) has been created in
https://codereview.chromium.org/1457963006/ by grt@chromium.org.

The reason for reverting is: Speculative revert for various test failures, e.g.
http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29...
and
http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%28....

[dcheng, 2015-11-20 21:15:57]

A revert of this CL (patchset #6 id:180001) has been created in
https://codereview.chromium.org/1458353004/ by dcheng@chromium.org.

The reason for reverting is: Causes
PaintPropertyTreeBuilderTest.PositionAndScroll and
DisplayItemTest.DebugStringsExist to fail on the debug bots..

[skobes, 2015-11-20 23:56:43]

Description was changed from

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::attachFrameContentLayersToIframeLayer must preserve
overflow controls just like the "!parented" path of GraphicsLayerTreeBuilder.

BUG=549174

Committed: https://crrev.com/bf0a5ac073c0844a514a979beab5c8b08a445393
Cr-Commit-Position: refs/heads/master@{#360860}
==========

to

==========
Clip scrollbars to box bounds when they don't fit.

There are three cases:

(1) scroller is a non-composited self-painting layer
(2) scroller is not a self-painting layer
(3) scroller is a composited layer
(3a) scroller is a composited layer that does not use composited scrolling

Case (1) already worked correctly through the background clip applied by
PaintLayerPainter.  Case (2) is addressed by the change in BlockPainter.

Case (3) is addressed by the changes in CompositedLayerMapping.  The clip is
applied by m_overflowControlsHostLayer.  GraphicsLayerTreeBuilder is modified
to preserve the layer tree in case (3a).

I have renamed m_overflowControlsClippingLayer for clarity, since the overflow
controls can now be clipped for two different reasons.

Note that for an iframe with CSS "resize", the scroll corner comes from the
iframe element's CompositedLayerMapping, not the inner PaintLayerCompositor.
For this reason, PLC::attachFrameContentLayersToIframeLayer must preserve
overflow controls just like the "!parented" path of GraphicsLayerTreeBuilder.

BUG=549174

Committed: https://crrev.com/bf0a5ac073c0844a514a979beab5c8b08a445393
Cr-Commit-Position: refs/heads/master@{#360860}
==========

[skobes, 2015-11-20 23:57:55]

PTAL

[chrishtr, 2015-11-21 23:34:11]

The CQ bit was checked by chrishtr@chromium.org

[chrishtr, 2015-11-21 23:34:11]

lgtm

[chrishtr, 2015-11-21 23:34:12]

The patchset sent to the CQ was uploaded after l-g-t-m from vollick@chromium.org
Link to the patchset: https://codereview.chromium.org/1448253002/#ps200001
(title: "fix assertion in clipTypeAsDebugString")

[commit-bot: I haz the power, 2015-11-21 23:34:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1448253002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1448253002/200001

[commit-bot: I haz the power, 2015-11-22 05:01:23]

Committed patchset #7 (id:200001)

[commit-bot: I haz the power, 2015-11-22 05:01:49]

Patchset 7 (id:??) landed as
https://crrev.com/74aa5e43fc22ffaa2538dca20aa36e22a3e9df38
Cr-Commit-Position: refs/heads/master@{#361037}