This issue is caused by couple reasons:

1. aura overlay scrollbar is show (opacity=1) at initial state. 
2. This page is a not scrollable page, then become scrollable (See attachment). We use to call DidiScrollUpdate (trigger the appear then fade out) when clip size change which removed at 697a467f819ce09da5209a3df13b8b92f33e35a4. So no DidiScrollUpdate called in proper timing. Before 697a467f819ce09da5209a3df13b8b92f33e35a4, this page works correctly.

LayerImpl::SetScrollable seems want to fix this issue.

LayerImpl::SetScrollable should get picked up by the ScrollbarAnimationController and eventually call DidScrollUpdate which should post a fade out, right? Do you know where this is going wrong?

SetScrollable and ScrollbarAnimationController may come from separate
commit and no promising order.

But I can not build a simple demo page.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fe2cab764f3300719159b98746a85ac5de8ba1d7

commit fe2cab764f3300719159b98746a85ac5de8ba1d7
Author: chaopeng <chaopeng@chromium.org>
Date: Mon Jul 17 15:35:10 2017

Do not push the reseted needs_show_scrollbars to active tree

This issue is caused by couple reasons:

1. aura overlay scrollbars are visible (opacity=1) at initial state.
2. page is a not scrollable, then become scrollable.
3. SetScrollable and ScrollbarAnimationController creation may come from
   separate commit and no promising order.

We use needs_show_scrollbars in layerImpl to indicate the layer need to call
SAC::DidRequestShowFromMainThread. If the SetScrollable call happens before SAC
and from separate commit then:

- first commit:

1. In TreeSynchronizer::PushLayerProperties, pending tree push to active tree
   SetScrollable, set needs_show_scrollbars because bounds change or scrollable
   flag change. then reset needs_show_scrollbars in the layer of pending tree.
   [1]
2. In HandleScrollbarShowRequestsFromMain, skip because SAC not found.

- second commit:

1. In TS::PushLayerProperties, pending tree set the needs_show_scrollbars(false)
   to active tree, then call SetScrollable and quick return because no bounds
   change or scrollable flag change.
2. In HandleScrollbarShowRequestsFromMain, skip because needs_show_scrollbars is
   false.

In this patch, we only push needs_show_scrollbars to active tree when
needs_show_scrollbars is true. So we do not use the reseted value to override
the value we keep for next pick up.

[1] https://chromium.googlesource.com/chromium/src/+/a7c2ee628552ec6a9d624dcd1b78442991615715/cc/layers/layer_impl.cc#329

Bug:  740795 
Change-Id: I15089ba357a67b3336bb251ce19cb2f7bf5953ba
Reviewed-on: https://chromium-review.googlesource.com/568815
Reviewed-by: Weiliang Chen <weiliangc@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487089}
[modify] https://crrev.com/fe2cab764f3300719159b98746a85ac5de8ba1d7/cc/layers/layer_impl.cc
[modify] https://crrev.com/fe2cab764f3300719159b98746a85ac5de8ba1d7/cc/layers/scrollbar_layer_unittest.cc

It's a one-line, trivial change which should be safe to merge, granted, we're fairly late in the game.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/85997065863790a2aa8aa1773d6ca7ea6a6a81fd

commit 85997065863790a2aa8aa1773d6ca7ea6a6a81fd
Author: David Bokan <bokan@chromium.org>
Date: Tue Jul 18 21:46:29 2017

Do not push the reseted needs_show_scrollbars to active tree

This issue is caused by couple reasons:

1. aura overlay scrollbars are visible (opacity=1) at initial state.
2. page is a not scrollable, then become scrollable.
3. SetScrollable and ScrollbarAnimationController creation may come from
   separate commit and no promising order.

We use needs_show_scrollbars in layerImpl to indicate the layer need to call
SAC::DidRequestShowFromMainThread. If the SetScrollable call happens before SAC
and from separate commit then:

- first commit:

1. In TreeSynchronizer::PushLayerProperties, pending tree push to active tree
   SetScrollable, set needs_show_scrollbars because bounds change or scrollable
   flag change. then reset needs_show_scrollbars in the layer of pending tree.
   [1]
2. In HandleScrollbarShowRequestsFromMain, skip because SAC not found.

- second commit:

1. In TS::PushLayerProperties, pending tree set the needs_show_scrollbars(false)
   to active tree, then call SetScrollable and quick return because no bounds
   change or scrollable flag change.
2. In HandleScrollbarShowRequestsFromMain, skip because needs_show_scrollbars is
   false.

In this patch, we only push needs_show_scrollbars to active tree when
needs_show_scrollbars is true. So we do not use the reseted value to override
the value we keep for next pick up.

[1] https://chromium.googlesource.com/chromium/src/+/a7c2ee628552ec6a9d624dcd1b78442991615715/cc/layers/layer_impl.cc#329

TBR=chaopeng@chromium.org

(cherry picked from commit fe2cab764f3300719159b98746a85ac5de8ba1d7)

Bug:  740795 
Change-Id: I15089ba357a67b3336bb251ce19cb2f7bf5953ba
Reviewed-on: https://chromium-review.googlesource.com/568815
Reviewed-by: Weiliang Chen <weiliangc@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#487089}
Reviewed-on: https://chromium-review.googlesource.com/576557
Cr-Commit-Position: refs/branch-heads/3112@{#642}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/85997065863790a2aa8aa1773d6ca7ea6a6a81fd/cc/layers/layer_impl.cc
[modify] https://crrev.com/85997065863790a2aa8aa1773d6ca7ea6a6a81fd/cc/layers/scrollbar_layer_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/08bc211aa6e21098474f43cd20c9c0b060e99b39

commit 08bc211aa6e21098474f43cd20c9c0b060e99b39
Author: Alex Mineer <amineer@chromium.org>
Date: Tue Jul 18 23:58:41 2017

Revert "Do not push the reseted needs_show_scrollbars to active tree"

This reverts commit 85997065863790a2aa8aa1773d6ca7ea6a6a81fd.

Breaks official Android build

https://uberchromegw.corp.google.com/i/official.android.continuous/builders/beta-arm/builds/8779

../../cc/layers/scrollbar_layer_unittest.cc: In member function 'virtual void cc::{anonymous}::AuraScrollbarLayerTest_ScrollbarLayerCreateAfterSetScrollable_Test::TestBody()':
../../cc/layers/scrollbar_layer_unittest.cc:829:17: error: 'class cc::Layer' has no member named 'SetScrollable'
   scroll_layer->SetScrollable(layer_tree_root->bounds());

BUG= 740795 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id2d4b862593e4e69bc1e27e349a0670b677178f7
Reviewed-on: https://chromium-review.googlesource.com/576528
Reviewed-by: Alex Mineer <amineer@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#646}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/08bc211aa6e21098474f43cd20c9c0b060e99b39/cc/layers/layer_impl.cc
[modify] https://crrev.com/08bc211aa6e21098474f43cd20c9c0b060e99b39/cc/layers/scrollbar_layer_unittest.cc

The merge got reverted. I found the issue but the tools don't seem to like accepting a second merge - I couldn't get help for this (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/_AdLD3kxJGo) and we've missed the stable cut it seems. I suppose this isn't a critical issue, perhaps -RBS? WDYT?

Agreed, I do not think this is critical fix for M60 hence removing RBS

You can merge-request for a subsequent M60 Stable refresh if merge issues are resolved and low risks