Bug 1595202 [wpt PR 20185] - [LayoutNGFragmentPaint] Fix containing-block of OOF...

Bug 1595202 [wpt PR 20185] - [LayoutNGFragmentPaint] Fix containing-block of OOF-positioned objects., a=testonly

Automatic update from web-platform-tests
[LayoutNGFragmentPaint] Fix containing-block of OOF-positioned objects.

We had an issue in the existing invalidation code when an object could
contain an OOF-positioned node, but wasn't a LayoutBlock.

This already happens when we have a LayoutInline being a
containing-block, but there are other cases where this is true.

Clusterfuzz found that LayoutTableSection falls into this category.
E.g.
The OOF-positioned node would be inserted into the nearest
containing-block (the anonymous LayoutTable in this case).

When it stopped being a containing-block, the OOF-positioned node was
never removed from the LayoutTable.

This caused a crash when the OOF's layout was invalidated.
The OOF marked itself, and the LayoutView (its new containing block)
for layout.

But the LayoutView didn't know it had this as an OOF-positioned child.

This patch moves the current logic within LayoutBlock into
LayoutBoxModelObject.

Bug: 1021491, 1021676, 1022545
Change-Id: I0f0b4c8aa655fc7edca5d79379205a8d445713d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1906708
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714487}

--

wpt-commits: 491cd874e7bb2487829f83df8b25b2b70b4c5e22
wpt-pr: 20185