Restore PaintLayerScrollableArea::ScrollbarManager::canDetach behavior.

Restore PaintLayerScrollableArea::ScrollbarManager::canDetach behavior.

This CL mistakenly disabled the 'detach' behavior for ScrollbarManager:

https://codereview.chromium.org/1930183002

... because it seemed like DelayScrollPositionClampScope would be sufficient
to preserve all the necessary state for scrollbars as they were added and
removed during the multiple layout passes of flex layout.  However, that
was premature: even though the scroll positions were preserved, destroying
and recreating scrollbars during layout will invalidate the
ScrollingCoordinator's mapping from Scrollbar to WebScrollbarLayer.

One side effect is that if a scroll event handler forces layout to run during
a scrollbar drag, and the Scrollbar/WebScrollbarLayer association is broken,
then the compositor will think that the scrollbar drag has ended, even though
mouse-up has not yet happened.

This CL also sneaks in a tiny optimization: if auto scrollbars are frozen,
then childFlexBasSizeRequiresLayout should not return true due to the child
having auto scrollbars (since the scrollbars cannot change).

BUG=617498
R=eae@chromium.org,cbiesinger@chromium.org

Committed: https://crrev.com/f56bda6f7f5201ace0327e8e64ddf41e9f52d2b5
Cr-Commit-Position: refs/heads/master@{#398193}

[eae, 2016-06-06 22:57:01]

LGTM

Please try to add a test in a follow up change.

[cbiesinger, 2016-06-06 23:23:42]

lgtm

https://codereview.chromium.org/2042923002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp (right):

https://codereview.chromium.org/2042923002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp:785: &&
!PaintLayerScrollableArea::FreezeScrollbarsScope::scrollbarsAreFrozen())));
We might want to split this up into separate statements; the nested boolean
operators are kinda hard to read at this point...

I'm also a little concerned about the side effect here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/La...

We now take the other branch in that if. I *think* that's ok, so lgtm.

[szager1, 2016-06-06 23:32:09]

The CQ bit was checked by szager@chromium.org

[commit-bot: I haz the power, 2016-06-06 23:33:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2042923002/1

[commit-bot: I haz the power, 2016-06-07 01:35:29]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-07 01:37:15]

Description was changed from

==========
Restore PaintLayerScrollableArea::ScrollbarManager::canDetach behavior.

This CL mistakenly disabled the 'detach' behavior for ScrollbarManager:

https://codereview.chromium.org/1930183002

... because it seemed like DelayScrollPositionClampScope would be sufficient
to preserve all the necessary state for scrollbars as they were added and
removed during the multiple layout passes of flex layout.  However, that
was premature: even though the scroll positions were preserved, destroying
and recreating scrollbars during layout will invalidate the
ScrollingCoordinator's mapping from Scrollbar to WebScrollbarLayer.

One side effect is that if a scroll event handler forces layout to run during
a scrollbar drag, and the Scrollbar/WebScrollbarLayer association is broken,
then the compositor will think that the scrollbar drag has ended, even though
mouse-up has not yet happened.

This CL also sneaks in a tiny optimization: if auto scrollbars are frozen,
then childFlexBasSizeRequiresLayout should not return true due to the child
having auto scrollbars (since the scrollbars cannot change).

BUG=617498
R=eae@chromium.org,cbiesinger@chromium.org
==========

to

==========
Restore PaintLayerScrollableArea::ScrollbarManager::canDetach behavior.

This CL mistakenly disabled the 'detach' behavior for ScrollbarManager:

https://codereview.chromium.org/1930183002

... because it seemed like DelayScrollPositionClampScope would be sufficient
to preserve all the necessary state for scrollbars as they were added and
removed during the multiple layout passes of flex layout.  However, that
was premature: even though the scroll positions were preserved, destroying
and recreating scrollbars during layout will invalidate the
ScrollingCoordinator's mapping from Scrollbar to WebScrollbarLayer.

One side effect is that if a scroll event handler forces layout to run during
a scrollbar drag, and the Scrollbar/WebScrollbarLayer association is broken,
then the compositor will think that the scrollbar drag has ended, even though
mouse-up has not yet happened.

This CL also sneaks in a tiny optimization: if auto scrollbars are frozen,
then childFlexBasSizeRequiresLayout should not return true due to the child
having auto scrollbars (since the scrollbars cannot change).

BUG=617498
R=eae@chromium.org,cbiesinger@chromium.org

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

[commit-bot: I haz the power, 2016-06-07 01:37:17]

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