Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

We turn a statically positioned object into an absolutely positioned one, and then delete it later on (setting it to display:none).

The parent object is a relatively positioned object inside a multicol container, so the absolutely positioned object should thus still be part of the multicol container (and flow thread). It's still column content that needs to be fragmented by the multicol container.

While the code in general realizes this, we failed to do so when dynamically taking it out-of-flow, so we ended up deleting a column set. When later setting display:none on the now-absolutely positioned object, we'd look for a column set to destroy, but it had already been destroyed.

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

commit 1c091b202047a6c391e6640c391d575d83398801
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Thu Apr 05 06:46:20 2018

Out-of-flow descendants may still be part of the flow thread.

When changing a layout object from in-flow to out-of-flow positioned, we
used to just remove it from the flow thread, risking that there'd no
longer be a column set to associate it with. However, an out-of-flow
positioned descendant may be contained by something that's inside the
flow thread, e.g. if the containing block of an absolutely positioned
object is a relatively positioned object, and that relatively positioned
object is contained by the flow thread.

Since it's hard to detect what the new containing block of an object is
going to be before it has actually gone out of flow, we'll still remove
it from the flow thread, but we'll now detect that we need to re-insert
it when computed style has updated.

Bug:  827424 
Change-Id: I413348b0d3ecd0c4b5051e6e9d2a4526863bef60
Reviewed-on: https://chromium-review.googlesource.com/995439
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548354}
[modify] https://crrev.com/1c091b202047a6c391e6640c391d575d83398801/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/1c091b202047a6c391e6640c391d575d83398801/third_party/WebKit/LayoutTests/external/wpt/css/css-multicol/going-out-of-flow-after-spanner.html
[modify] https://crrev.com/1c091b202047a6c391e6640c391d575d83398801/third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.cpp

ClusterFuzz has detected this issue as fixed in range 548353:548354.

Detailed report: https://clusterfuzz.com/testcase?key=5028923059208192

Fuzzer: ifratric-browserfuzzer-v3
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  blink::LayoutMultiColumnFlowThread::FlowThreadDescendantWillBeRemoved
  blink::LayoutObject::RemoveFromLayoutFlowThreadRecursive
  blink::LayoutObject::WillBeRemovedFromTree
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=523880:523906
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=548353:548354

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5028923059208192

See https://github.com/google/clusterfuzz-tools for more information.

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

ClusterFuzz testcase 5028923059208192 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.