[LayoutNG] Fix stability issues with NGBlockLayoutAlgorithm. #16907
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...we had all the right concepts, but we're holding them the wrong way.
This patch does a few inter-related things to ensure we don't have
different parts of the block layout algorithm fighting each other.
Previously we could end up in a state where a child believed it should
be placed at a particular BFC-block-offset, and the parent disagreeing
with that. This caused us to perform three layouts, and fail the
DCHECK_EQ(layout_result->Status(), kSuccess) check.
(if we did the layouts in a loop, this would otherwise result in a
timeout).
This introduces/changes:
end of the layout algorithm. If we didn't resolve our BFC
block-offset, or were an empty-inline line-box we get this flag.
This flag is more stable than checking if the
NGLayoutResult::BlockBfcOffset had a value as this would sometimes
be present for empty-blocks.
NGConstraintSpace::ForcedBfcBlockOffset. This is used in almost
an identical way, except that:
(unless shifted by clearance).
like exclusion spaces are. Only at the end of an algorithm do we
determine if they should be "passed" up to a parent based on if it
is an empty block or not.
This helps in determining clearance past adjoining floats.
more complex check to determine if the current layout should be
considered as "clearing" floats also.
block-offset, and adds the "ancestor has clearance past adjoining
floats" flag.
Bug: 962344, 962300
Change-Id: Ife4030847f2e2b97aa5726072fadf581696ab8e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1611111
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#661462}