Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 49.0.2623.87

This is a Non-Regression issue existing from M30 - # - 30.0.1549.0

Have you seen this before oshima?

The expected behavior is that scrollbar gets toggled every 3 seconds right?
If so, this seems to be working on ToT (and probably 50 as well).

rnimmagadda@, can you test this on 50?

By the way, Blink hits the following assertion when I load that page on Debug build.  eae@, who would be good person to look into this?


ASSERTION FAILED: !floatBox.hasSelfPaintingLayer()
../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp(2651) : static void blink::LayoutBlockFlow::setAncestorShouldPaintFloatingObject(const blink::LayoutBox &, bool)
1   0x7f2e9697c509 blink::LayoutBlockFlow::setAncestorShouldPaintFloatingObject(blink::LayoutBox const&, bool)
2   0x7f2e97230d22 blink::PaintLayer::didUpdateNeedsCompositedScrolling()
3   0x7f2e9724c4a1 blink::PaintLayerScrollableArea::updateNeedsCompositedScrolling(blink::PaintLayerScrollableArea::LCDTextMode)
4   0x7f2e9722f4db blink::PaintLayer::didUpdateCompositingInputs()
5   0x7f2e96adf0d7
6   0x7f2e96adefb8
7   0x7f2e96adefb8
8   0x7f2e96adefb8
9   0x7f2e96ade7dd
10  0x7f2e96ae72b6 blink::PaintLayerCompositor::updateIfNeeded()
11  0x7f2e96ae6edb blink::PaintLayerCompositor::updateIfNeededRecursive()
12  0x7f2e96ae6d2d blink::PaintLayerCompositor::updateIfNeededRecursive()
13  0x7f2e96f89c91 blink::FrameView::updateLifecyclePhasesInternal(blink::FrameView::LifeCycleUpdateOption)
14  0x7f2e96f899b2 blink::FrameView::updateAllLifecyclePhases()
15  0x7f2e971c37e7 blink::PageAnimator::updateAllLifecyclePhases(blink::LocalFrame&)
16  0x7f2eab69e615

Also happening in Chrome 50

2 layout tests crash due to this bug in debug. So we have coverage. The new composite opaque scrollers path hits this and it has always hit on --enable-prefer-compositing-to-lcd-text.

imported/csswg-test/vendor-imports/mozilla/mozilla-central-reftests/flexbox/flexbox-overflow-horiz-001.html
fast/overflow/overflow-float-stacking.html

And the assertion has changed:
SHOULD NEVER BE REACHED
../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp(3368) : static void blink::LayoutBlockFlow::setAncestorShouldPaintFloatingObject(const blink::LayoutBox &)
1   0x7f67dc512190 blink::LayoutBlockFlow::setAncestorShouldPaintFloatingObject(blink::LayoutBox const&)
2   0x7f67dc87ae59 blink::PaintLayer::didUpdateNeedsCompositedScrolling()
3   0x7f67dc8986bf blink::PaintLayerScrollableArea::updateNeedsCompositedScrolling(blink::PaintLayerScrollableArea::LCDTextMode)

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

commit 7081b331ccd1903e0b3cc539d8decccb0a09863d
Author: schenney <schenney@chromium.org>
Date: Thu Sep 22 22:09:27 2016

Fix assertions related to floats and z-order lists when compositing opaque scrollers

The codepath for compositing opaque scrollers, enabled by
--enable-blink-feature="CompositeOpaqueScrollbars", was triggering two asserts.

One assertion was due to querying stacking order lists when those lists were
dirty. The assertion is fixed by updating the stacking order lists if needed
before the query, only if we actually need to look at the list.

The other assertion was a side-effect of an earlier change to remove a
different assertion, https://codereview.chromium.org/2191953002. The code
in question is attempting to update the shouldPaint flag of a FloatingObject
when that object has had a change in selfPaintingLayer status. But because
selfPaintingLayer status has already been updated, and the query for
FloatingObject::shouldPaint() checks the current selfPaintingLayer status,
we have no way of finding out if a floating object with a selfpaintingLayer
was previously shouldPaint. We were requiring that shouldPaint return
true so that we could set it false and return, but instead we were falling
out of the loop and hitting an ASSERT_NOT_REACHED.

The fix is to not check the previous status and just set shouldPaint to false
for all FloatingObject where the object has a selfPaintingLayer, and not assert
not reached as now we might exit the loop. We are no longer returning as soon
as we update the shouldPaint to false because we can no longer be sure that
we are actually changing the value of shouldPaint.

The lack of assertions allows 2 webkit_unit_tests to pass without crashing,
and prevents crashes in a slew of LayoutTests. Of note,
fast/overflow/overflow-float-stacking.html no longer crashes, but does fail
analogously to fast/overflow/overflow-stacking.html. In
https://codereview.chromium.org/1826013002 we had decided to live with that
failure as it is a manifestation of the fundamental compositing bug that
users on high DPI devices have always seen.

R=wangxianzhu@chromium.org,flackr@chromium.org
BUG= 593097 , 381840 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[modify] https://crrev.com/7081b331ccd1903e0b3cc539d8decccb0a09863d/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp
[modify] https://crrev.com/7081b331ccd1903e0b3cc539d8decccb0a09863d/third_party/WebKit/Source/core/paint/PaintLayer.cpp

Works now and no asserts.