Don't call paginatedContentWasLaidOut() until we have the final layout.

Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
Committed: https://crrev.com/9958b7d0b612a7b1bbea85f1c8f2825faa5cebb6
Cr-Commit-Position: refs/heads/master@{#387548}

[mstensho (USE GERRIT), 2016-04-14 18:05:37]

Description was changed from

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need a relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place would make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional and unneeded fragmentainer groups.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
==========

to

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
==========

[mstensho (USE GERRIT), 2016-04-14 18:09:25]

mstensho@opera.com changed reviewers:
+ leviw@chromium.org

[mstensho (USE GERRIT), 2016-04-14 18:09:26]

That mythical other CL that's mentioned in the description is
https://codereview.chromium.org/1891783002/ - but that one depends on this one,
so let's do this one first. :)

Also, am I supposed to add szager to multicol / fragmentation reviews from now
on?

[leviw_travelin_and_unemployed, 2016-04-14 22:20:34]

On 2016/04/14 at 18:09:26, mstensho wrote:
> That mythical other CL that's mentioned in the description is
https://codereview.chromium.org/1891783002/ - but that one depends on this one,
so let's do this one first. :)
> 
> Also, am I supposed to add szager to multicol / fragmentation reviews from now
on?

I'm trying to find someone who has the fortitude to handle the coming multicol
onslaught. szager@ sits next to me, so he was the first name that popped up...
I'm not sure he's quite signed off on it yet.

Anyways: LGTM.

[mstensho (USE GERRIT), 2016-04-15 06:14:26]

On 2016/04/14 22:20:34, leviw wrote:
> On 2016/04/14 at 18:09:26, mstensho wrote:
> > Also, am I supposed to add szager to multicol / fragmentation reviews from
now
> on?
> 
> I'm trying to find someone who has the fortitude to handle the coming multicol
> onslaught. szager@ sits next to me, so he was the first name that popped up...
> I'm not sure he's quite signed off on it yet.

All right. I'll just keep on throwing the patches at you for now, until you let
me know. :)

[mstensho (USE GERRIT), 2016-04-15 06:14:32]

The CQ bit was checked by mstensho@opera.com

[commit-bot: I haz the power, 2016-04-15 06:14:41]

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

[commit-bot: I haz the power, 2016-04-15 07:11:23]

Description was changed from

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
==========

to

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
==========

[commit-bot: I haz the power, 2016-04-15 07:11:25]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-04-15 07:12:35]

Description was changed from

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833
==========

to

==========
Don't call paginatedContentWasLaidOut() until we have the final layout.

Blocks may need relayout because of pagination, and calling
paginatedContentWasLaidOut() before that has taken place could make us account
for a leading pagination strut twice (once before the block child, and once
before the first line inside the block). In a nested multicol context this
could trigger creation of additional fragmentainer groups that will be
unneeded in the end.

This fixes the assertion mentioned in bug 594833, but new ones will pop up
instead, because of brokenness in the column balancer. That will be fixed in a
separate CL.

BUG=594833

Committed: https://crrev.com/9958b7d0b612a7b1bbea85f1c8f2825faa5cebb6
Cr-Commit-Position: refs/heads/master@{#387548}
==========

[commit-bot: I haz the power, 2016-04-15 07:12:36]

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