DescriptionAlways lay out the flow thread when the multicol container is laid out.
This makes it possible to put an auto-height multicol inside another
auto-height multicol. It goes like this: first we balance the inner multicol
without knowing the height of the outer one. When we know the height of the
inner one, we can balance the outer one, and re-lay out.
markForPaginationRelayoutIfNeeded() will make sure that the inner multicol
container is marked for layout in that pass, and here it is crucial that we
enter its flow thread too, since that's where the contents are (so that we
realize that the outer multicol is height-restricted, so that we need to insert
an additional row (fragmentainer group) for the inner one).
This change triggers an additional flow thread layout pass in some cases, which
exposed crbug.com/534751 in two layout tests, so I modified the tests somewhat
to avoid triggering the additional layout pass altogether.
Explanation for the extra layout pass: When initially laying out a document,
and the document doesn't specify whether scrollbars should be shown or not,
Blink assumes that there will be a vertical scrollbar. If we find out after
layout that there's no need for it, it is removed, followed by another layout
pass, because removing the scrollbar gave the viewport a new width.
When an object changes its width, all children will be marked for layout. This
also happens if a child's width is fixed (which admittedly really seems
unnecessary).
Example:
<!DOCTYPE html>
<html>
<body>
<div id="outer" style="width:100px;">
<div id="inner"></div>
When the initial vertical scrollbar is removed, the viewport width changes, so
HTML and BODY need to be laid out again, since their widths are auto.
Additionally, we lay out #outer, because it's a child of something that got a
new width (even if the child has a fixed width). But at least we won't re-lay
out #inner, since its parent doesn't change its width.
The tests that had to be modified had a fixed-width multicol container child of
BODY, which got re-laid out when the initial scrollbar disappeared. With this
CL, its child flow thread would also be re-laid out, which would expose
crbug.com/534751 , since laying out a paginated table twice is one way of
triggering that bug.
BUG=447718
R=leviw@chromium.org
Committed: https://crrev.com/d131cacd36ca82c0a866d8caed6dce0fed30f588
Cr-Commit-Position: refs/heads/master@{#357393}
Patch Set 1 #Messages
Total messages: 6 (1 generated)
|