Regression information is not available. The result is the blame information.

Author: wangxianzhu
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/a6c054a66a5365513c6023206dc9eecbbe4f1641
Time: Tue Jan 26 08:15:02 2016
The CL last changed line 1259 of file LayoutObject.cpp, which is stack frame 0.
=========================
Above mentioned is the CL's list from findit, Suspecting the file of "LayoutObject.cpp" from the frame #0 .

wangxianzhu@: Observed some recent changes on this file, Could you please look into this issue if it is related to your change, else please help us in assigning it to the right owner.

Thanks!

For the following case:
<div style="-webkit-columns:2;">
  <div style="position: relative">
    <div style="-webkit-column-span:all;">
  </div>
</div>

The layout tree is:
LayoutView     	                #document
  LayoutBlockFlow  	        HTML
    LayoutBlockFlow    	        BODY
      LayoutBlockFlow     	DIV STYLE="-webkit-columns:2;"
        LayoutMultiColumnFlowThread (anonymous)
          LayoutBlockFlow (relative positioned)	DIV STYLE="position: relative;"
            LayoutBlockFlow (column spanner) 	DIV STYLE="-webkit-column-span:all;"
        LayoutMultiColumnSet (anonymous)
        LayoutMultiColumnSpannerPlaceholder (anonymous)

For now enclosingLayer() of the spanner is the relative-position object's layer whose self-painting container layer is the layoutView's layer. The actual self-painting container layer of the spanner is the column container. This has the following problems when the spanner is invalidated out of paint invalidation phase (e.g. when it is removed):

1. We'll miss setNeedsRepaint on its real self-painting container layer;

2. We may invalidate the spanner on wrong backing because enclosingCompositedContainer() may not be the real paintInvalidationContainer of the spanner.

(We don't have problem in paint invalidation phase because we track paintInvalidationContainer and enclosingSelfPaintingLayer correctly which doesn't rely on LayoutObject::enclosingLayer().)

I tried to change LayoutObject::enclosingLayer() to return the real container layer for column-span:all (https://codereview.chromium.org/1955073002/), but it causes failures of fast/multicol/dynamic/abspos-multicol-with-spanner-becomes-spanner.html and fast/multicol/span/abspos-containing-block-outside-spanner.html.

It seems that at some places we still need enclosingLayer() return the enclosing layer in layout tree hierarchy.

Any hint?

The containing block of a column spanner is always the multicol container. So we need to skip any objects/layers between those two objects (jumping sideways from the spanner to its placeholder and then to its parent (the multicol container) is the fast way). If that's too awkward (I see that you have filed a CL, so maybe not), we could consider having spanners always establish a layer - a non-self-painting (am I saying it right?) one, like for instance statically positioned objects with non-visible overflow.

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

commit 8895ae9799f7de65a747c97b6f2442d83717463d
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Mon May 09 20:15:12 2016

LayoutObject::paintingLayer() to correctly handle column-span:all

When finding the layer painting an object, we should traverse up the tree
through spanner placeholder when meeting a column-span:all object.

BUG= 609720 
TEST=fast/multicol/span/remove-span-all-under-layer.html

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

[add] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/LayoutTests/fast/multicol/span/remove-spanner-under-relative-position-expected.txt
[add] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/LayoutTests/fast/multicol/span/remove-spanner-under-relative-position.html
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutBlockFlowLine.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutObjectChildList.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/LayoutTable.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp
[modify] https://crrev.com/8895ae9799f7de65a747c97b6f2442d83717463d/third_party/WebKit/Source/core/layout/PaintInvalidationState.h

ClusterFuzz has detected this issue as fixed in range 392347:392418.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4534403551723520

Fuzzer: mbarbella_js_mutation_layout
Job Type: linux_debug_content_shell_drt
Platform Id: linux

Crash Type: ASSERT
Crash Address: 
Crash State:
  ASSERTION FAILED: !enclosingSelfPaintingLayer || enclosingSelfPaintingLayer->nee
  blink::assertEnclosingSelfPaintingLayerHasSetNeedsRepaint
  blink::LayoutObject::invalidatePaintOfPreviousPaintInvalidationRect
  
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=392347:392418

Minimized Testcase (0.23 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94_xQapgUFGlk67S2LFTP704_Vbdxpv_7efsct3dafk0nWH5Gr-d-irTa8T5mCpFUt3vKhP62q_mvxjMYesYSHTZ02199ymrAd1CxSOkghAfH54EEueOxFcCuwjYwJLBB_0pv1bQotfTN03EQlDjUKGD2h6qQ
<div style="-webkit-columns:2;">
   <div id="container">
    <div style="-webkit-column-span:all;">
  <script>
    document.getElementById("container").style.position = "relative";
</script>
  <style>
body > div {
    display: inline-block;


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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