GitLab

We'd end up re-entering NGBlockNode::CopyFragmentDataToLayoutBox() for
the same node.

After layout of a fragment, NGBlockNode::CopyFragmentDataToLayoutBox() would
call LayoutBlock::UpdateAfterLayout(), which would call
scrollbar was toggled, it'd go ahead and call UpdateLayout() on the object,
which would take us back into the NG layout machinery, on the same node, via
Finally we'd re-enter NGBlockNode::CopyFragmentDataToLayoutBox(), causing misc
kinds of misery, such as not being able to paint the block at all. For
multicol, there'd even be a DCHECK failure "Variable fragment inline size not
supported", because the code got confused as to whether a fragment was a first
fragment or not.

LayoutBox: :UpdateAfterLayout(), which would call
PaintLayer: :UpdateSizeAndScrollingAfterLayout(), which would call
PaintLayerScrollableArea: :UpdateAfterLayout(). If this code detected that a
LayoutNGBlockFlow: :UpdateBlockLayout(), further to NGBlockNode::Layout().
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_layout_ng;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I832372223e324682bb4e38b3177dce30093df2e1
Reviewed-on: https://chromium-review.googlesource.com/824265
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524039}