Class A fragmentainer break points also exist between zero-height blocks.

Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

R=leviw@chromium.org
BUG=223068
Committed: https://crrev.com/fe283ea1ad33abe251cbb4a921f7f836085bab82
Cr-Commit-Position: refs/heads/master@{#380625}

[mstensho (USE GERRIT), 2016-03-04 10:30:43]

Description was changed from

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on margin collapsing
information (atBeforeSideOfBlock), but that's not entirely correct. It's
obviously okay to collapse margins through a zero-height block, and basically
pretend that it doesn't exist for the sake of margin collapsing. But this isn't
true for fragmentation. Class A break points [1] exist between any two in-flow
blocks, regardless of the height of said blocks. Therefore we cannot propagate
the pagination strut caused by a line inside a block following an empty
first-child block.

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

R=leviw@chromium.org
==========

to

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on margin collapsing
information (atBeforeSideOfBlock), but that's not entirely correct. It's
obviously okay to collapse margins through a zero-height block, and basically
pretend that it doesn't exist for the sake of margin collapsing. But this isn't
true for fragmentation. Class A break points [1] exist between any two in-flow
blocks, regardless of the height of said blocks. Therefore we cannot propagate
the pagination strut caused by a line inside a block following an empty
first-child block.

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

[mstensho (USE GERRIT), 2016-03-07 10:10:52]

Description was changed from

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on margin collapsing
information (atBeforeSideOfBlock), but that's not entirely correct. It's
obviously okay to collapse margins through a zero-height block, and basically
pretend that it doesn't exist for the sake of margin collapsing. But this isn't
true for fragmentation. Class A break points [1] exist between any two in-flow
blocks, regardless of the height of said blocks. Therefore we cannot propagate
the pagination strut caused by a line inside a block following an empty
first-child block.

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

to

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for 
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

[mstensho (USE GERRIT), 2016-03-10 19:09:23]

@leviw: ping

[leviw_travelin_and_unemployed, 2016-03-10 21:23:59]

lgtm

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp (right):

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:161: class
BlockChildrenLayoutInfo {
I'm in love with context objects in layout and happily accept them starting to
show up.

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:724: // If we're not
at the first in-flow child, there's a class A break point before the child. If
we *are* at the
I kind of hate these class names. Can we link to the spec in this comment?

[mstensho (USE GERRIT), 2016-03-11 10:18:49]

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp (right):

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:161: class
BlockChildrenLayoutInfo {
On 2016/03/10 21:23:59, leviw wrote:
> I'm in love with context objects in layout and happily accept them starting to
> show up.

Soon there'll be even moar context! :)

https://codereview.chromium.org/1769483002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:724: // If we're not
at the first in-flow child, there's a class A break point before the child. If
we *are* at the
On 2016/03/10 21:23:59, leviw wrote:
> I kind of hate these class names. Can we link to the spec in this comment?

Done.

[mstensho (USE GERRIT), 2016-03-11 10:20:08]

The CQ bit was checked by mstensho@opera.com

[mstensho (USE GERRIT), 2016-03-11 10:20:08]

The patchset sent to the CQ was uploaded after l-g-t-m from leviw@chromium.org
Link to the patchset: https://codereview.chromium.org/1769483002/#ps60001
(title: "Link to the scriptures.")

[commit-bot: I haz the power, 2016-03-11 10:20:21]

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

[commit-bot: I haz the power, 2016-03-11 14:19:27]

Description was changed from

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for 
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

to

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for 
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

[commit-bot: I haz the power, 2016-03-11 14:19:28]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-11 14:20:53]

Description was changed from

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for 
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

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

to

==========
Class A fragmentainer break points also exist between zero-height blocks.

We used to base class A break point [1] detection on whether we were at the
start of the container, location-wise (atBeforeSideOfBlock). That's not
sufficient. It's obviously okay to collapse margins through a zero-height
block, and basically pretend that it doesn't exist for the sake of margin
collapsing. But this isn't true for fragmentation. Class A break points [1]
exist between any two in-flow blocks, regardless of the height of said blocks.
Therefore we cannot propagate the pagination strut caused by a line inside a
block following an empty first-child block. We still need to keep the check for
whether we are at the start of the container, though, because if we aren't, it
means that we have a class C break point [1].

This CL introduces the BlockChildrenLayoutInfo class, which is used as a state
object during block children layout. This replaces MarginInfo and LayoutUnit
previousFloatLogicalBottom, which is what we used to pass back and forth. They
have now been wrapped into BlockChildrenLayoutInfo, along with a new piece of
information: whether we're laying out the first in-flow child or not. This
information is what we now use to detect if we're at a class A break point [1]
or not.

[1] https://drafts.csswg.org/css-break/#possible-breaks

R=leviw@chromium.org
BUG=223068

Committed: https://crrev.com/fe283ea1ad33abe251cbb4a921f7f836085bab82
Cr-Commit-Position: refs/heads/master@{#380625}
==========

[commit-bot: I haz the power, 2016-03-11 14:20:54]

Patchset 4 (id:??) landed as
https://crrev.com/fe283ea1ad33abe251cbb4a921f7f836085bab82
Cr-Commit-Position: refs/heads/master@{#380625}