Improve strut handling in initial column balancing pass.

Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.

Committed: https://crrev.com/5c2f73741d5087c50451a67089e26b071982acd1
Cr-Commit-Position: refs/heads/master@{#433166}

[mstensho (USE GERRIT), 2016-11-17 21:39:24]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-11-17 21:41:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mstensho (USE GERRIT), 2016-11-17 21:59:13]

mstensho@opera.com changed reviewers:
+ eae@chromium.org, szager@chromium.org

[mstensho (USE GERRIT), 2016-11-17 21:59:13]

I'm trying to get rid of some pagination code from
LayoutBlockFlow::layoutBlockFlow() before I refactor the code there. See
https://codereview.chromium.org/2471623003/

We currently have this:
  if (pageLogicalHeightChanged)
    relayoutChildren = true;

I want to get rid of it, but it turns out that these two lines of code hide a
lot of bugs that are still be reproducible with some extra effort (typically,
just wrap everything inside another DIV or two and watch things go bananas).

This should be the final CL required to get rid of that code. Other CLs
previously landed:
https://codereview.chromium.org/2493833004
https://codereview.chromium.org/2473953003
https://codereview.chromium.org/2474883002

[eae, 2016-11-17 22:01:24]

This is awesome!

LGTM

[commit-bot: I haz the power, 2016-11-17 23:05:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-17 23:05:40]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[mstensho (USE GERRIT), 2016-11-18 09:12:51]

Description was changed from

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass. Almost more importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.
==========

to

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more
importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.
==========

[mstensho (USE GERRIT), 2016-11-18 09:13:04]

The CQ bit was checked by mstensho@opera.com

[mstensho (USE GERRIT), 2016-11-18 09:13:04]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2509813004/#ps20001
(title: "Rebaseline for column-rules-fixed-height. This test no longer triggers
deep layout.")

[commit-bot: I haz the power, 2016-11-18 09:13:20]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-18 10:27:56]

Description was changed from

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more
importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.
==========

to

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more
importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.
==========

[commit-bot: I haz the power, 2016-11-18 10:27:57]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-11-18 10:30:09]

Description was changed from

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more
importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.
==========

to

==========
Improve strut handling in initial column balancing pass.

Only use the pagination strut from the first object or line (in each parallel
flow [1]) that we find at a page break. When we need to break before some
content, we may end up setting the pagination strut on some ancestor of said
content, rather than on the content (layout object or line box). This happens
when there's no break opportunity (class A, B or C break point [2]) before the
content that doesn't fit in its current fragmentainer (there's no break
opportunity before the first line in a block, for instance). In such cases we
need to propagate the strut to some ancestor that comes after a valid break
opportunity. In such situations, there'll be severeal layout objects or line
boxes that start at the exact top of the next fragmentainer. Only the first
object in layout tree order will have the strut. Subsequent objects (children,
typically) or lines that also are flush with the top of the fragmentainer will
have a strut of 0. We shouldn't overwrite the actual strut with 0, or we risk
overstretching the columns. At each break we need to know the exact amount of
space that was "wasted" because of the break, and subtract it, in order to
calculate a minimal column height.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows
[2] https://www.w3.org/TR/css-break-3/#possible-breaks

We also need to make sure that we associate breaks with the right column when
balancing, i.e. the former column, not the latter. This distinction matters if
the pagination strut is 0 and we're at the exact top/bottom of some column.

This CL also enables using specified column height even when balancing a
multicol container. It may be that the final column height will actually be the
same as the specified height, which means that if we set it right away, we
might be able to eliminate a subsequent layout pass [1]. Almost more
importantly,
doing this will exercise code in the column balancer that was previously only
used when balancing inside nested multicol. This in turn means that it will
become less cumbersome to write tests for this code, and hopefully more
difficult for bugs to hide in there as well.

[1] LayoutTests/paint/invalidation/column-rules-fixed-height.html no longer
requires the contents of the multicol container to be relaid out when
column-rule changes.

Committed: https://crrev.com/5c2f73741d5087c50451a67089e26b071982acd1
Cr-Commit-Position: refs/heads/master@{#433166}
==========

[commit-bot: I haz the power, 2016-11-18 10:30:10]

Patchset 2 (id:??) landed as
https://crrev.com/5c2f73741d5087c50451a67089e26b071982acd1
Cr-Commit-Position: refs/heads/master@{#433166}