commit e3add48b23d857f84e5a77f10405fe1e5c796db1
author Aleks Totic <atotic@chromium.org> Tue Mar 05 21:47:40 2019
committer Commit Bot <commit-bot@chromium.org> Tue Mar 05 21:47:40 2019
tree 52c1764f6a2cb6095ede6ae1fef3382c02674326
parent 2f034a6e32fcf150338108b6d5740586e821d58d

[LayoutNG] Fix access to deleted OOF descendant

This patch fixes the reported crash. The reproducible case is
https://ajuntament.barcelona.cat/widgets/socials/bcn/index.html?lang=es&numRows=1&header&menu&boxColor=aab0b0&buttonColor=aab0b0&buttonRadius=50&fontColor=ffffff&id=3c58a16711f992fee70edcf13ef72da3

Unfortunately, I have been unable to create a minimal reproducible
case that causes a crash. The added test case exercises new
code path, just without a crash.

The bug observed at the crashing URL was:

LayoutResult::OOFPositionedDescendants had an invalid descendant
that was already removed from the tree. What made this failure extra
annoying is that memory occupied by invalid descendant was reused
for a different LayoutObject.

Removal of the descendant caused LayoutObject::MarkContainerChainForLayout
to be called, but the container chain was not fully traversed because
ObjectIsRelayoutBoundary returned true and aborted the traversal.

My understanding is as following. In 2015, leviw introduced an
invalidation optimization. The optimization happens when
child needs layout, but can guarantee that it will not affect
layout of its parent.

In this case, child stops marking parents for relayout, and is
instead put on LayoutSubtreeRootList, which gets traversed
for layout directly. Method that does this is
LocalFrameView::ScheduleRelayoutOfSubtree

The method that decides whether child affects parents layout is:
ObjectIsRelayoutBoundary(). I've fixed this method for NG, so
that cached layout result with oof descendants causes full
container chain traversal.

Bug: 933054
Change-Id: Ie3daab53937297f1cea75b0974c3fce353c86200
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500610
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#637821}