column-span:all in nested multicol requires re-insertion of fragmentainer groups.

column-span:all in nested multicol requires re-insertion of fragmentainer groups.

A column set that follows a spanner will typically have an incorrect logical
top in the first layout pass (because the spanner hasn't been laid out yet). We
already have code in place to make sure that we re-lay out when we need to, but
we also need to delete and re-insert fragmentainer groups when this happens in
a nested fragmentation context.

If a column set gets a new logical top, it means that previously inserted
fragmentainer groups are now out of sync with reality, and have to be
re-inserted.

Remove the BalancedColumnHeightCalculation enum. There's no need for it
anymore, since picking calculation mode is now something we need to do for each
individual column set. m_tallestUnbreakableLogicalHeight is now reset in
resetColumnHeight() (that's where it ought to have been all along, anyway).

BUG=447718
R=leviw@chromium.org

Committed: https://crrev.com/7829897fa89bec64fa0dbc45471d1fa784ead98d
Cr-Commit-Position: refs/heads/master@{#362492}

[mstensho (USE GERRIT), 2015-12-01 15:15:22]

Span span span span span span span!

https://www.youtube.com/watch?v=M_eYSuPKP3Y

[leviw_travelin_and_unemployed, 2015-12-01 18:26:41]

LGTM. Where the hell do you come up with these test cases? :p

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/multicol/span/after-row-with-uneven-height-nested-multicol.html
(right):

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/after-row-with-uneven-height-nested-multicol.html:3:
body { overflow:hidden; } /* Prevent extra layout pass (which could hide the
problem) */
Scrollbar spam!

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html
(right):

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:8:
.sausage { background:brown; }
Honestly, CSS brown is not my favorite color for sausage.

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:17:
<div style="line-height:30px;">
I feel like you need two rows of bread for this to be a complete sandwich.

I was, however, informed that Norwegians eat many sandwiches open face, so
perhaps just one on the bottom?

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:26:
<div class="fakeColumn sausage"></div>
Why no wide sausage?

[mstensho (USE GERRIT), 2015-12-01 18:48:13]

The CQ bit was checked by mstensho@opera.com

[commit-bot: I haz the power, 2015-12-01 18:48:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1489663003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1489663003/1

[mstensho (USE GERRIT), 2015-12-01 18:55:56]

Thanks for reviewing. Glad you like the test cases. The next one will have beer
in it! Stay tuned. :)

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html
(right):

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:8:
.sausage { background:brown; }
On 2015/12/01 18:26:41, leviw wrote:
> Honestly, CSS brown is not my favorite color for sausage.

What _I_ don't get, is why there is no color named "sausage", when there are
colors named after lesser foods, such as "salmon".

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:17:
<div style="line-height:30px;">
On 2015/12/01 18:26:41, leviw wrote:
> I feel like you need two rows of bread for this to be a complete sandwich.
> 
> I was, however, informed that Norwegians eat many sandwiches open face, so
> perhaps just one on the bottom?

Low-carb!

https://codereview.chromium.org/1489663003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/multicol/span/nested-multicol-expected.html:26:
<div class="fakeColumn sausage"></div>
On 2015/12/01 18:26:41, leviw wrote:
> Why no wide sausage?

Sorry. EU directive. :(

[eae, 2015-12-01 19:23:49]

On 2015/12/01 18:55:56, mstensho wrote:
> Sorry. EU directive. :(

Darn those bureaucrats!

[commit-bot: I haz the power, 2015-12-01 20:56:03]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-12-01 20:57:31]

Description was changed from

==========
column-span:all in nested multicol requires re-insertion of fragmentainer
groups.

A column set that follows a spanner will typically have an incorrect logical
top in the first layout pass (because the spanner hasn't been laid out yet). We
already have code in place to make sure that we re-lay out when we need to, but
we also need to delete and re-insert fragmentainer groups when this happens in
a nested fragmentation context.

If a column set gets a new logical top, it means that previously inserted
fragmentainer groups are now out of sync with reality, and have to be
re-inserted.

Remove the BalancedColumnHeightCalculation enum. There's no need for it
anymore, since picking calculation mode is now something we need to do for each
individual column set. m_tallestUnbreakableLogicalHeight is now reset in
resetColumnHeight() (that's where it ought to have been all along, anyway).

BUG=447718
R=leviw@chromium.org
==========

to

==========
column-span:all in nested multicol requires re-insertion of fragmentainer
groups.

A column set that follows a spanner will typically have an incorrect logical
top in the first layout pass (because the spanner hasn't been laid out yet). We
already have code in place to make sure that we re-lay out when we need to, but
we also need to delete and re-insert fragmentainer groups when this happens in
a nested fragmentation context.

If a column set gets a new logical top, it means that previously inserted
fragmentainer groups are now out of sync with reality, and have to be
re-inserted.

Remove the BalancedColumnHeightCalculation enum. There's no need for it
anymore, since picking calculation mode is now something we need to do for each
individual column set. m_tallestUnbreakableLogicalHeight is now reset in
resetColumnHeight() (that's where it ought to have been all along, anyway).

BUG=447718
R=leviw@chromium.org

Committed: https://crrev.com/7829897fa89bec64fa0dbc45471d1fa784ead98d
Cr-Commit-Position: refs/heads/master@{#362492}
==========

[commit-bot: I haz the power, 2015-12-01 20:57:31]

Patchset 1 (id:??) landed as
https://crrev.com/7829897fa89bec64fa0dbc45471d1fa784ead98d
Cr-Commit-Position: refs/heads/master@{#362492}