Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LayoutNGFragmentPaint] Fix containing-block of OOF-positioned objects. #20185

Merged
merged 1 commit into from Nov 12, 2019

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Nov 8, 2019

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}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-1906708 branch 3 times, most recently from 279bcdb to 34bb526 Compare November 11, 2019 23:53
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}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants