Couldn't reproduce the bug.

falken@, how frequently can you reproduce the bug?

Hm, I can reproduce on my primary Chrome profile that has many different tabs open, but not in a clean profile --user-data-dir=/tmp/aeroigjaeogji.

I also had to disable some other asserts that were firing to reach one ( issue 639100 ) not sure that's related.

@falken have you seen the failure since Oct?

I'm closing this bug. Please reopen if it is encountered again.

Sure. Sorry about the lack of response to comment 4. I don't recall seeing this bug in a while.

We are seeing this in one of our configurations and it's reproducing consistently.

Can you tell us how severe that DCHECK is? Will this only mean a performance penalty or could there be visual artifacts coming this?

It means that an object in a layer is invalidated without the layer is invalidated. In the next paint, we'll still use the cached painting of the whole layer, including the invalidated object. This will cause visual artifacts.

Can you share the reproduction method?

> It means that an object in a layer is invalidated without the layer is invalidated. In the next paint, we'll still use the cached painting of the whole layer, including the invalidated object. This will cause visual artifacts.

Thanks, I suspected this but hoped I was wrong. The solution I tried was to add a call to object.paintingLayer()->setNeedsRepaint() in ObjectPaintInvalidator::invalidatePaintIncludingNonCompositingDescendants. This solves the problem of hitting the DCHECK but my guess is that this is not a desired solution because of the performance penalties described in the comments.

> Can you share the reproduction method?
Unfortunately, we use this in a proprietary setup with a custom platform implementation that I can't share. I have tried to reproduce this in both chrome and content_shell but was unable to do so.

Thanks for the analysis. invalidatePaintIncludingNonCompositingDescendants() contains code that invalidate any self painting layer encountered during the tree walk, which should be equivalent to calling object.paintingLayer()->setNeedsRepaint() on every object. The failure means that the tree walk order may be wrong at some places. Will investigate.

I suspect this is related to the following pattern:
  <div>
    <span>
      <div style="float: left"></div>
    </span>
  </div>

We just fixed some bugs about such scheme, but I found invalidatePaintIncludingNonCompositingDescendants() may still have issues about it.

landell@ does your setup contain such pattern?

I tried with that snippet but didn't hit the DCHECK while scrolling.
I have been reproducing with http://edition.cnn.com/2016/12/12/politics/china-trump-one-china-reaction/index.html but the URL in this issue also works.

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

commit f105471106f4c821364165bdd991ce13196f5496
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Tue Jan 24 08:15:34 2017

Fix traverseNonCompositingDescendantsInPaintOrder for float-under-inline cases

We should traverse into composited inlines even if they are stacking
context, because there might be floating objects which belong to
ancestors in paint order.

During traverse for paint invalidation, when we encounter a floating
object, we should mark the real painting layer for paint invalidation
which may be above the tip of the subtree being traversed.

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

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

[modify] https://crrev.com/f105471106f4c821364165bdd991ce13196f5496/third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp
[modify] https://crrev.com/f105471106f4c821364165bdd991ce13196f5496/third_party/WebKit/Source/core/paint/ObjectPaintInvalidatorTest.cpp

Thanks, the CL resolves our propblems.

Thanks for the feedback. I tried the cnn links and couldn't reproduce with the patch. Can you still reproduce with the cnn links?

No, I can't reproduce with the patch applied.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(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/+/246f4f0482e90289fd249360c558f9cee734f122

commit 246f4f0482e90289fd249360c558f9cee734f122
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Wed Jan 25 17:58:26 2017

Fix traverseNonCompositingDescendantsInPaintOrder for float-under-inline cases

We should traverse into composited inlines even if they are stacking
context, because there might be floating objects which belong to
ancestors in paint order.

During traverse for paint invalidation, when we encounter a floating
object, we should mark the real painting layer for paint invalidation
which may be above the tip of the subtree being traversed.

BUG= 644144 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
TBR=wangxianzhu@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2639283003
Cr-Original-Commit-Position: refs/heads/master@{#445679}
Review-Url: https://codereview.chromium.org/2657853002
Cr-Commit-Position: refs/branch-heads/2987@{#87}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/246f4f0482e90289fd249360c558f9cee734f122/third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp
[modify] https://crrev.com/246f4f0482e90289fd249360c558f9cee734f122/third_party/WebKit/Source/core/paint/ObjectPaintInvalidatorTest.cpp