Narrow Bisect info:
https://chromium.googlesource.com/chromium/src/+log/7caea6eeb8d0cbce90c6749bd21a436a6f372e56..622df80e954a2ead9cdd6f242ae7bf301dd81bda?pretty=fuller&n=10000

Suspecting : r397888 from Narrow Bisect

Note : 
1. The same issue is also seen under 'Console' panel in devtools.

Deleted: Act_scrollbar.mp4 1.2 MB

Act_scrollbar.mp4 1.2 MB Download

Deleted: Expec_scrollbar.mp4 840 KB

Expec_scrollbar.mp4 840 KB Download

Deleted: Actual_Console_Panel_scrollbar.mp4 1.2 MB

Actual_Console_Panel_scrollbar.mp4 1.2 MB Download

Able to reproduce the issue on win8.1 chrome version 53.0.2760.0

Adding RB label as this is a recent regression

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

commit f56bda6f7f5201ace0327e8e64ddf41e9f52d2b5
Author: szager <szager@chromium.org>
Date: Tue Jun 07 01:35:16 2016

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

Review-Url: https://codereview.chromium.org/2042923002
Cr-Commit-Position: refs/heads/master@{#398193}

[modify] https://crrev.com/f56bda6f7f5201ace0327e8e64ddf41e9f52d2b5/third_party/WebKit/Source/core/layout/LayoutFlexibleBox.cpp
[modify] https://crrev.com/f56bda6f7f5201ace0327e8e64ddf41e9f52d2b5/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp

Retested the above issue on All-OS(Windows 7 & 10, Mac 10.11.5 & Ubuntu 14.04) with chrome version '53.0.2763.0' & scroll bar is not getting stuck which scrolling file list in source panel, hence marking the same as TE-Verified-53.0.2763.0.

Attach is the video for the  same.

Thank you!

Deleted: Retest-9June.mp4 3.0 MB

	Retest-9June.mp4 3.0 MB View Download

szager@, could you please mark this issue as 'Fixed'?

Thank you!

 Issue 624117  has been merged into this issue.