Disable overlay scrollbars in Blink when hidden by the compositor.

Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/169f5add2dd64e14cb89c8ac388bc81cc32121d8
Cr-Commit-Position: refs/heads/master@{#428628}

[bokan, 2016-10-25 22:11:36]

Description was changed from

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
==========

to

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[bokan, 2016-10-25 22:11:37]

Description was changed from

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[bokan, 2016-10-25 22:15:44]

bokan@chromium.org changed reviewers:
+ aelias@chromium.org

[bokan, 2016-10-25 22:15:45]

Alexandre, since Blink is responsible for handling all the input on scrollbars
but the compositor is responsible for hiding them we need some way to sync the
two about when the scrollbars are actually showing, otherwise the user can click
and drag a scrollbar that's been faded out. If you're ok with this approach I'll
add tests and put up a new patch. WDYT?

[aelias_OOO_until_Jul13, 2016-10-25 22:32:04]

> otherwise the user can click and drag a scrollbar that's been faded out

A high-level question I have about this is so what?  Would anyone complain? 
Isn't the whole system designed to show the scrollbar ASAP when the mouse hovers
over it?  If there's a time interval where a very fast user can click on a
scrollbar that isn't visible yet, then I think the best fix would just be to
make the scrollbar fade in faster.

[bokan, 2016-10-25 23:06:35]

On 2016/10/25 22:32:04, aelias wrote:
> > otherwise the user can click and drag a scrollbar that's been faded out
> 
> A high-level question I have about this is so what?  Would anyone complain? 
> Isn't the whole system designed to show the scrollbar ASAP when the mouse
hovers
> over it?  If there's a time interval where a very fast user can click on a
> scrollbar that isn't visible yet, then I think the best fix would just be to
> make the scrollbar fade in faster.

The scrollbars fade in only when the user scrolls. If the user hasn't scrolled
and they go to try clicking something (e.g. a link) that's where the scrollbar
would be, they'll activate the scrollbar rather than clicking the link.

[aelias_OOO_until_Jul13, 2016-10-26 02:53:02]

On 2016/10/25 at 23:06:35, bokan wrote:
> The scrollbars fade in only when the user scrolls. If the user hasn't scrolled
and they go to try clicking something (e.g. a link) that's where the scrollbar
would be, they'll activate the scrollbar rather than clicking the link.

That doesn't make sense to me.  What's the point of supporting scrollbar
dragging at all if you first need to use a different scroll modality to kick
things off?  That seems really confusing and seems bound to lead to the same
kind of complaints we got when first trying to launch overlay scrollbars on
desktop.  Why not fade them in when the mouse approaches, just as they thicken
when the mouse approaches?  That seems better from both a UX and code complexity
point of view.

[bokan, 2016-10-26 13:38:46]

On 2016/10/26 02:53:02, aelias wrote:
> On 2016/10/25 at 23:06:35, bokan wrote:
> > The scrollbars fade in only when the user scrolls. If the user hasn't
scrolled
> and they go to try clicking something (e.g. a link) that's where the scrollbar
> would be, they'll activate the scrollbar rather than clicking the link.
> 
> That doesn't make sense to me.  What's the point of supporting scrollbar
> dragging at all if you first need to use a different scroll modality to kick
> things off?  That seems really confusing and seems bound to lead to the same
> kind of complaints we got when first trying to launch overlay scrollbars on
> desktop.

I didn't design the interaction, but I don't find it all that strange. Dragging
a scrollbar is useful mostly for quickly scrolling a long way. A user typically
won't know they want/need to do that until they've scrolled a bit and realize
it's very long. Also, this is exactly how Mac overlay scrollbars work and that
seems to work well in practice. (The way this is implemented on Mac is we
actually repaint the scrollbars on the main thread so a busy page janks
scrollbar animations).

> Why not fade them in when the mouse approaches, just as they thicken
> when the mouse approaches?  That seems better from both a UX and code
complexity
> point of view.

That still doesn't help the fact that the scrollbars may be overlaying something
you want to click on. As a concrete example, the landing page on
codereview.chromium.org has a "This is Rietveld 9387bc4" link that's right at
the bottom of the page. Currently with overlay scrollbars on, if my window is
small enough to have horizontal scrolling, there's no way to click that link
since the scrollbars handle it.

[bokan, 2016-10-26 15:54:17]

Description was changed from

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[aelias_OOO_until_Jul13, 2016-10-26 19:01:03]

OK, thanks for the context, overall approach SGTM.

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
File cc/input/scrollbar_animation_controller.h (right):

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
cc/input/scrollbar_animation_controller.h:67: int scroll_layer_id_;
Please leave this private and introduce a protected getter instead.

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
File cc/input/scrollbar_animation_controller_thinning.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
cc/input/scrollbar_animation_controller_thinning.cc:218: if (opacity_ == 0.0f ||
opacity_ == 1.0f)
I think this if statement could just be removed with no ill effect, an
early-return in SetScrollbarsHidden should do the job and there's no reason to
treat 0.1 differently from 1.0.

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc#newcode100
cc/layers/layer.cc:100: scrollbars_hidden_(false),
This state is redundant with the one in ScrollableArea, please delete it.  This
would mean getting rid of the early-return in
Layer::SetScrollbarsHiddenFromImplSide().  There's already early-return coverage
in ScrollableArea::didChangeScrollbarsHidden() and you just need to add
analogous early-return to FrameView::didChangeScrollbarsHidden().

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc#newcode829
cc/layers/layer.cc:829: 
nit: unnecessary newline

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
cc/trees/layer_tree_host_impl.cc:2225: client_->SetNeedsCommitOnImplThread();
Please check if any of the map entries changed and only SetNeedsCommit if so.

[bokan, 2016-10-27 20:56:20]

Description was changed from

==========
<WIP> Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[bokan, 2016-10-27 20:56:27]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[bokan, 2016-10-27 20:56:46]

Tests added, ptal.

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
File cc/input/scrollbar_animation_controller.h (right):

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
cc/input/scrollbar_animation_controller.h:67: int scroll_layer_id_;
On 2016/10/26 19:01:03, aelias wrote:
> Please leave this private and introduce a protected getter instead.

Done.

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
File cc/input/scrollbar_animation_controller_thinning.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/input/scrollbar_animatio...
cc/input/scrollbar_animation_controller_thinning.cc:218: if (opacity_ == 0.0f ||
opacity_ == 1.0f)
On 2016/10/26 19:01:03, aelias wrote:
> I think this if statement could just be removed with no ill effect, an
> early-return in SetScrollbarsHidden should do the job and there's no reason to
> treat 0.1 differently from 1.0.

Done.

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc#newcode100
cc/layers/layer.cc:100: scrollbars_hidden_(false),
On 2016/10/26 19:01:03, aelias wrote:
> This state is redundant with the one in ScrollableArea, please delete it. 
This
> would mean getting rid of the early-return in
> Layer::SetScrollbarsHiddenFromImplSide().
Done.

> There's already early-return coverage
> in ScrollableArea::didChangeScrollbarsHidden() and you just need to add
> analogous early-return to FrameView::didChangeScrollbarsHidden().

FrameView::didChangeScrollbarsHidden and
PaintLayerScrollableArea::didChangeScrollbarsHidden are only called from
ScrollableArea::setScrollbarsHidden (that's what you meant above) if there's a
change so they don't need an early return.

https://codereview.chromium.org/2453553003/diff/1/cc/layers/layer.cc#newcode829
cc/layers/layer.cc:829: 
On 2016/10/26 19:01:03, aelias wrote:
> nit: unnecessary newline

Done.

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
cc/trees/layer_tree_host_impl.cc:2225: client_->SetNeedsCommitOnImplThread();
On 2016/10/26 19:01:03, aelias wrote:
> Please check if any of the map entries changed and only SetNeedsCommit if so.

The map is cleared on each commit so that it contains only layers with changed
scrollbar visibility (to avoid iterating over all scroll layers each commit). We
could remove existing and non-equal entries rather than flipping the bit since
that means we've changed back and forth without a commit, but SetNeedsCommit
will have already been set by the first call.

Since this flag is synced one-way only, we don't have a record of what the main
thread thinks this value is so we can't compare against that either.

I've added this bit to LayerImpl so we can avoid spamming NeedsCommit if nothing
on impl has changed.

[commit-bot: I haz the power, 2016-10-27 20:57:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 21:04:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 21:04:23]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_precise_blink_rel/...)
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[aelias_OOO_until_Jul13, 2016-10-27 21:22:09]

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/2453553003/diff/1/cc/trees/layer_tree_host_im...
cc/trees/layer_tree_host_impl.cc:2225: client_->SetNeedsCommitOnImplThread();
On 2016/10/27 at 20:56:46, bokan wrote:
> On 2016/10/26 19:01:03, aelias wrote:
> > Please check if any of the map entries changed and only SetNeedsCommit if
so.
> 
> The map is cleared on each commit so that it contains only layers with changed
scrollbar visibility (to avoid iterating over all scroll layers each commit). We
could remove existing and non-equal entries rather than flipping the bit since
that means we've changed back and forth without a commit, but SetNeedsCommit
will have already been set by the first call.
> 
> Since this flag is synced one-way only, we don't have a record of what the
main thread thinks this value is so we can't compare against that either.
> 
> I've added this bit to LayerImpl so we can avoid spamming NeedsCommit if
nothing on impl has changed.

OK.  Though with that bit added to LayerImpl, the scrollbars_hidden_map_ state
isn't needed anymore.  Please just put scrollbar visibility boolean into
info->scrollbars on every commit.  The early-return on the main thread side will
take care of avoiding substantive work from that.

[aelias_OOO_until_Jul13, 2016-10-27 21:22:51]

On 2016/10/27 at 21:22:09, aelias wrote:
> OK.  Though with that bit added to LayerImpl, the scrollbars_hidden_map_ state
isn't needed anymore.  Please just put scrollbar visibility boolean into
info->scrollbars on every commit.  The early-return on the main thread side will
take care of avoiding substantive work from that.

Sorry missed a word, I meant "Please just put *every* scrollbar visibility
boolean into info->scrollbars on every commit."

[aelias_OOO_until_Jul13, 2016-10-27 21:24:11]

lgtm modulo that

[bokan, 2016-10-28 12:07:27]

On 2016/10/27 21:22:51, aelias wrote:
> On 2016/10/27 at 21:22:09, aelias wrote:
> > OK.  Though with that bit added to LayerImpl, the scrollbars_hidden_map_
state
> isn't needed anymore.  Please just put scrollbar visibility boolean into
> info->scrollbars on every commit.  The early-return on the main thread side
will
> take care of avoiding substantive work from that.
> 
> Sorry missed a word, I meant "Please just put *every* scrollbar visibility
> boolean into info->scrollbars on every commit."

Since we're now posting all the states over every commit, I've removed the
state on LayerImpl (as well as the map) and just keep track of the visibility
state internally in the ScrollbarAnimationController, only prodding LTHI to
SetNeedsCommit if it changes.

[bokan, 2016-10-28 12:16:23]

bokan@chromium.org changed reviewers:
+ vollick@chromium.org

[bokan, 2016-10-28 12:16:24]

+vollick@ for Source/platform and ui/compositor OWNER

[bokan, 2016-10-28 13:00:19]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 13:00:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 13:35:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 13:35:12]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[bokan, 2016-10-28 14:06:06]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 14:06:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 14:53:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 14:53:40]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[bokan, 2016-10-28 14:59:49]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 15:00:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 15:18:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 15:18:23]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[bokan, 2016-10-28 15:20:09]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 15:20:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 17:05:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 17:05:32]

Dry run: This issue passed the CQ dry run.

[Ian Vollick, 2016-10-29 03:23:10]

On 2016/10/28 12:16:24, bokan wrote:
> +vollick@ for Source/platform and ui/compositor OWNER

lgtm

[bokan, 2016-10-29 21:10:15]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-10-29 21:10:16]

The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org
Link to the patchset: https://codereview.chromium.org/2453553003/#ps140001
(title: "Another Win Fix (comparing unsigned vs bool)")

[commit-bot: I haz the power, 2016-10-29 21:10:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-29 21:13:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-29 21:13:18]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[bokan, 2016-10-29 22:00:39]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-10-29 22:00:40]

The patchset sent to the CQ was uploaded after l-g-t-m from
vollick@chromium.org, aelias@chromium.org
Link to the patchset: https://codereview.chromium.org/2453553003/#ps160001
(title: "Rebase")

[commit-bot: I haz the power, 2016-10-29 22:00:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-29 23:09:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-29 23:09:18]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bokan, 2016-10-30 14:59:05]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2016-10-30 14:59:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-30 16:33:13]

Description was changed from

==========
Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[commit-bot: I haz the power, 2016-10-30 16:33:15]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-10-30 16:48:51]

Description was changed from

==========
Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Disable overlay scrollbars in Blink when hidden by the compositor.

This patch adds and plumbs through a one-way notification from the compositor's
impl thread to Blink. This is used to prevent Blink from handling user input on
Scrollbars in cases where they've been hidden, as happens when overlay
scrollbars remain idle for a small amount of time. This patch makes use of this
setting when fading out scrollbars on the compositor but this will also be used
in Blink when scrollbars are faded-out there for non-composited scrollers. This
should have no visible effect for anything but Aura overlay scrollbars.

BUG=652826
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/169f5add2dd64e14cb89c8ac388bc81cc32121d8
Cr-Commit-Position: refs/heads/master@{#428628}
==========

[commit-bot: I haz the power, 2016-10-30 16:48:52]

Patchset 9 (id:??) landed as
https://crrev.com/169f5add2dd64e14cb89c8ac388bc81cc32121d8
Cr-Commit-Position: refs/heads/master@{#428628}