Use Layout Opportunity Iterator to position new FC blocks.

Use Layout Opportunity Iterator to position new FC blocks.

This patch fixes the use case when we need to use Layout Opportunity
Iterator to position a block that establishes a new formatting context.

BUG=635619
TEST=NGBlockLayoutAlgorithmTest.NewFcBlockWithAdjoiningFloatCollapsesMargins

Review-Url: https://codereview.chromium.org/2816933003
Cr-Commit-Position: refs/heads/master@{#465899}
Committed: https://chromium.googlesource.com/chromium/src/+/c873e8003e60b30ff8bd65fd345b70faf77cd700

[Gleb Lanbin, 2017-04-13 19:51:50]

Patchset #1 (id:1) has been deleted

[Gleb Lanbin, 2017-04-13 19:52:11]

glebl@chromium.org changed reviewers:
+ ikilpatrick@chromium.org

[Gleb Lanbin, 2017-04-13 19:53:28]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-13 19:54:04]

Dry run: 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, 2017-04-13 19:58:00]

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

[commit-bot: I haz the power, 2017-04-13 19:58:01]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ikilpatrick, 2017-04-14 10:42:28]

I'll look at this tomorrow morning.

[Gleb Lanbin, 2017-04-14 22:46:34]

On 2017/04/14 10:42:28, ikilpatrick wrote:
> I'll look at this tomorrow morning.

Also I tried a bit more complicated example
https://docs.google.com/document/d/1xiwqdIHm-2NdYOEHXMjUOrXSfCPf9fE093bWeS4Ya....
I think LayoutNG lays out that example very close to how it should be, i.e.
without any overlapping etc.

[ikilpatrick, 2017-04-17 08:17:16]

On 2017/04/14 22:46:34, Gleb Lanbin wrote:
> On 2017/04/14 10:42:28, ikilpatrick wrote:
> > I'll look at this tomorrow morning.
> 
> Also I tried a bit more complicated example
>
https://docs.google.com/document/d/1xiwqdIHm-2NdYOEHXMjUOrXSfCPf9fE093bWeS4Ya....
> I think LayoutNG lays out that example very close to how it should be, i.e.
> without any overlapping etc.

So in that example change contain: paint, to overflow: hidden, edge/FF may not
support that yet.

[ikilpatrick, 2017-04-17 08:17:25]

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:139:
NGLogicalOffset NGBlockLayoutAlgorithm::PositionNewFc(
might be worth writing up here which case this covers, (and why it's gross).

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:139:
NGLogicalOffset NGBlockLayoutAlgorithm::PositionNewFc(
.nit, so i like having these types of methods close to where they are used,
thoughts on moving them below ::FinishChildLayout?

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:141: const
NGConstraintSpace* child_space) {
you aren't modifying child_space right? so this should be a ref?

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:154:
&tmp_builder);
is there an easy way we can avoid tmp_builder here?

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:169: // 4.
Child's BFC block's offset is known here.
4. The child's BFC block offset is known here.

?

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:393: if
(!IsNewFormattingContextForBlockLevelChild(Style(), *child))
you don't strictly need to do this right?

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:422: //
Determine the fragment's position in the parent space.
Yay! thanks for pulling these out.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:465: // No
need to postpone the positioning if we know the correct offset.
can you add a newline above this line? (just having trouble with separation
here).

[Gleb Lanbin, 2017-04-17 21:49:53]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[Gleb Lanbin, 2017-04-17 21:50:10]

PTAL

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:139:
NGLogicalOffset NGBlockLayoutAlgorithm::PositionNewFc(
On 2017/04/17 08:17:24, ikilpatrick wrote:
> .nit, so i like having these types of methods close to where they are used,
> thoughts on moving them below ::FinishChildLayout?

Done.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:139:
NGLogicalOffset NGBlockLayoutAlgorithm::PositionNewFc(
On 2017/04/17 08:17:24, ikilpatrick wrote:
> might be worth writing up here which case this covers, (and why it's gross).

Done.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:141: const
NGConstraintSpace* child_space) {
On 2017/04/17 08:17:24, ikilpatrick wrote:
> you aren't modifying child_space right? so this should be a ref?

Done.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:154:
&tmp_builder);
On 2017/04/17 08:17:24, ikilpatrick wrote:
> is there an easy way we can avoid tmp_builder here?

Done.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:169: // 4.
Child's BFC block's offset is known here.
On 2017/04/17 08:17:24, ikilpatrick wrote:
> 4. The child's BFC block offset is known here.
> 
> ?

Done.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:393: if
(!IsNewFormattingContextForBlockLevelChild(Style(), *child))
On 2017/04/17 08:17:24, ikilpatrick wrote:
> you don't strictly need to do this right?

the decision about whether we should append margins for a new FC block happens
in PositionNewFc method.
  if (opportunity.offset.block_offset == curr_bfc_offset_.block_offset)
    curr_margin_strut_.Append(curr_child_margins_.block_start);

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:422: //
Determine the fragment's position in the parent space.
On 2017/04/17 08:17:24, ikilpatrick wrote:
> Yay! thanks for pulling these out.

Acknowledged.

https://codereview.chromium.org/2816933003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:465: // No
need to postpone the positioning if we know the correct offset.
On 2017/04/17 08:17:24, ikilpatrick wrote:
> can you add a newline above this line? (just having trouble with separation
> here).

Done.

[commit-bot: I haz the power, 2017-04-17 21:50:14]

Dry run: 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, 2017-04-17 22:15:08]

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

[commit-bot: I haz the power, 2017-04-17 22:15:08]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[ikilpatrick, 2017-04-18 13:19:56]

lgtm

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:325: //
Non empty border/padding, new FC use cases are handled inside of the
.nit Non empty border/padding, and new FC use cases.... 

(oxford comma)

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:418:
opportunity = FindLayoutOpportunityForFragment(
will this always be just:

LayoutUnit block_offset_delta = curr_margin_strut_.Sum(); // (bad name).
curr_bfc_offset_.block_offset += block_offset_delta;
curr_margin_strut_ = {};
// ^ (step 3).

opportunity.offset.block_offset += block_offset_delta;
// ^ (step 5)
?

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_floats_utils.cc (right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_floats_utils.cc:32: // Finds a
layout opportunity for the fragment.
update comments?

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h (right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h:70: void
PositionPendingFloats(LayoutUnit origin_block_offset) {
if there is another way to do this i'd prefer that, as this is very block-flow
specific... i.e. no other layout algorithms will use this. 

Could do the same thing as MaybeUpdateFragmentBfcOffset for now?

Or might be time to do this block/inline specific sub-class.

[Gleb Lanbin, 2017-04-18 17:30:20]

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:325: //
Non empty border/padding, new FC use cases are handled inside of the
On 2017/04/18 13:19:55, ikilpatrick wrote:
> .nit Non empty border/padding, and new FC use cases.... 
> 
> (oxford comma)

Done.

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:418:
opportunity = FindLayoutOpportunityForFragment(
On 2017/04/18 13:19:55, ikilpatrick wrote:
> will this always be just:
> 
> LayoutUnit block_offset_delta = curr_margin_strut_.Sum(); // (bad name).
> curr_bfc_offset_.block_offset += block_offset_delta;
> curr_margin_strut_ = {};
> // ^ (step 3).
> 
> opportunity.offset.block_offset += block_offset_delta;
> // ^ (step 5)
> ?

we need to call FindLayoutOpportunityForFragment one more time because we might
have intruding floats that we need to take into account after  we determined the
position of parent's fragment.

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_floats_utils.cc (right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_floats_utils.cc:32: // Finds a
layout opportunity for the fragment.
On 2017/04/18 13:19:55, ikilpatrick wrote:
> update comments?

I just deleted this comment. We don't need it anymore because
1) it's a private method
2) it's very clear what it does from its name.

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h (right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h:70: void
PositionPendingFloats(LayoutUnit origin_block_offset) {
On 2017/04/18 13:19:56, ikilpatrick wrote:
> if there is another way to do this i'd prefer that, as this is very block-flow
> specific... i.e. no other layout algorithms will use this. 
> 
> Could do the same thing as MaybeUpdateFragmentBfcOffset for now?
> 
> Or might be time to do this block/inline specific sub-class.

yes, I was thinking about that as well. Here are 4 options:

1) Make NGInlineLayoutAlgorithm to inherit NGBlockLayoutAlgorithm. That's
because NGInlineLayoutAlgorithm produces a block fragment as as result.

2) (SELECTED) Leave PositionPendingFloats in NGLayoutAlgorithm base class for
now but have an annotation that it should be only used by
NG{Block|Inline}Algorithms. Later we can decide what to do with them

3) Make PositionPendingFloats static. But that will make PositionPendingFloats
usage not very convenient. 

4) Create an interim base class for Block/Inline algorithms.

[Gleb Lanbin, 2017-04-18 17:30:25]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 17:30:59]

Dry run: 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, 2017-04-18 19:24:27]

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

[commit-bot: I haz the power, 2017-04-18 19:24:28]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[cbiesinger, 2017-04-18 19:36:43]

cbiesinger@chromium.org changed reviewers:
+ cbiesinger@chromium.org

[cbiesinger, 2017-04-18 19:36:43]

just a couple of brief comments I noticed. also, does this not fix any layout
tests?

https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:227:
FinishFloatChildLayout(child->Style(), *child_space, &*layout_result);
I would prefer .get() over &*

https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.h
(right):

https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.h:52:
NGLogicalOffset PrepareChildLayout(NGLayoutInputNode*);
This needs a comment about what this is returning

[Gleb Lanbin, 2017-04-18 20:20:46]

On 2017/04/18 19:36:43, cbiesinger wrote:
> just a couple of brief comments I noticed. also, does this not fix any layout
> tests?

I haven't checked what LayouTests we may start passing because we're in the
middle of deprecating virtual/layout_ng/css2.1/20110323. Once it's done. I will
re-run everything and update TestExpectations.  


>
https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
> (right):
> 
>
https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:227:
> FinishFloatChildLayout(child->Style(), *child_space, &*layout_result);
> I would prefer .get() over &*
> 

done

>
https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.h
> (right):
> 
>
https://codereview.chromium.org/2816933003/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.h:52:
> NGLogicalOffset PrepareChildLayout(NGLayoutInputNode*);
> This needs a comment about what this is returning

done

[ikilpatrick, 2017-04-18 21:04:11]

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:418:
opportunity = FindLayoutOpportunityForFragment(
On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> On 2017/04/18 13:19:55, ikilpatrick wrote:
> > will this always be just:
> > 
> > LayoutUnit block_offset_delta = curr_margin_strut_.Sum(); // (bad name).
> > curr_bfc_offset_.block_offset += block_offset_delta;
> > curr_margin_strut_ = {};
> > // ^ (step 3).
> > 
> > opportunity.offset.block_offset += block_offset_delta;
> > // ^ (step 5)
> > ?
> 
> we need to call FindLayoutOpportunityForFragment one more time because we
might
> have intruding floats that we need to take into account after  we determined
the
> position of parent's fragment.

thanks, yup.

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h (right):

https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h:70: void
PositionPendingFloats(LayoutUnit origin_block_offset) {
On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> On 2017/04/18 13:19:56, ikilpatrick wrote:
> > if there is another way to do this i'd prefer that, as this is very
block-flow
> > specific... i.e. no other layout algorithms will use this. 
> > 
> > Could do the same thing as MaybeUpdateFragmentBfcOffset for now?
> > 
> > Or might be time to do this block/inline specific sub-class.
> 
> yes, I was thinking about that as well. Here are 4 options:
> 
> 1) Make NGInlineLayoutAlgorithm to inherit NGBlockLayoutAlgorithm. That's
> because NGInlineLayoutAlgorithm produces a block fragment as as result.
> 
> 2) (SELECTED) Leave PositionPendingFloats in NGLayoutAlgorithm base class for
> now but have an annotation that it should be only used by
> NG{Block|Inline}Algorithms. Later we can decide what to do with them
> 
> 3) Make PositionPendingFloats static. But that will make PositionPendingFloats
> usage not very convenient. 
> 
> 4) Create an interim base class for Block/Inline algorithms.

My preferred option here would be (4) in a follow up patch. We'll need to be
very principled about only simple methods in the base class.

[Gleb Lanbin, 2017-04-18 22:07:20]

On 2017/04/18 21:04:11, ikilpatrick wrote:
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
> (right):
> 
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:418:
> opportunity = FindLayoutOpportunityForFragment(
> On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> > On 2017/04/18 13:19:55, ikilpatrick wrote:
> > > will this always be just:
> > > 
> > > LayoutUnit block_offset_delta = curr_margin_strut_.Sum(); // (bad name).
> > > curr_bfc_offset_.block_offset += block_offset_delta;
> > > curr_margin_strut_ = {};
> > > // ^ (step 3).
> > > 
> > > opportunity.offset.block_offset += block_offset_delta;
> > > // ^ (step 5)
> > > ?
> > 
> > we need to call FindLayoutOpportunityForFragment one more time because we
> might
> > have intruding floats that we need to take into account after  we determined
> the
> > position of parent's fragment.
> 
> thanks, yup.
> 
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h (right):
> 
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h:70: void
> PositionPendingFloats(LayoutUnit origin_block_offset) {
> On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> > On 2017/04/18 13:19:56, ikilpatrick wrote:
> > > if there is another way to do this i'd prefer that, as this is very
> block-flow
> > > specific... i.e. no other layout algorithms will use this. 
> > > 
> > > Could do the same thing as MaybeUpdateFragmentBfcOffset for now?
> > > 
> > > Or might be time to do this block/inline specific sub-class.
> > 
> > yes, I was thinking about that as well. Here are 4 options:
> > 
> > 1) Make NGInlineLayoutAlgorithm to inherit NGBlockLayoutAlgorithm. That's
> > because NGInlineLayoutAlgorithm produces a block fragment as as result.
> > 
> > 2) (SELECTED) Leave PositionPendingFloats in NGLayoutAlgorithm base class
for
> > now but have an annotation that it should be only used by
> > NG{Block|Inline}Algorithms. Later we can decide what to do with them
> > 
> > 3) Make PositionPendingFloats static. But that will make
PositionPendingFloats
> > usage not very convenient. 
> > 
> > 4) Create an interim base class for Block/Inline algorithms.
> 
> My preferred option here would be (4) in a follow up patch. We'll need to be
> very principled about only simple methods in the base class.

ok, lets choose a name for that class then. NGBaseBlockLayoutAlgorithm ?

[Gleb Lanbin, 2017-04-19 16:25:16]

On 2017/04/18 22:07:20, Gleb Lanbin wrote:
> On 2017/04/18 21:04:11, ikilpatrick wrote:
> >
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
> > (right):
> > 
> >
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:418:
> > opportunity = FindLayoutOpportunityForFragment(
> > On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> > > On 2017/04/18 13:19:55, ikilpatrick wrote:
> > > > will this always be just:
> > > > 
> > > > LayoutUnit block_offset_delta = curr_margin_strut_.Sum(); // (bad name).
> > > > curr_bfc_offset_.block_offset += block_offset_delta;
> > > > curr_margin_strut_ = {};
> > > > // ^ (step 3).
> > > > 
> > > > opportunity.offset.block_offset += block_offset_delta;
> > > > // ^ (step 5)
> > > > ?
> > > 
> > > we need to call FindLayoutOpportunityForFragment one more time because we
> > might
> > > have intruding floats that we need to take into account after  we
determined
> > the
> > > position of parent's fragment.
> > 
> > thanks, yup.
> > 
> >
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h (right):
> > 
> >
>
https://codereview.chromium.org/2816933003/diff/40001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/core/layout/ng/ng_layout_algorithm.h:70: void
> > PositionPendingFloats(LayoutUnit origin_block_offset) {
> > On 2017/04/18 17:30:20, Gleb Lanbin wrote:
> > > On 2017/04/18 13:19:56, ikilpatrick wrote:
> > > > if there is another way to do this i'd prefer that, as this is very
> > block-flow
> > > > specific... i.e. no other layout algorithms will use this. 
> > > > 
> > > > Could do the same thing as MaybeUpdateFragmentBfcOffset for now?
> > > > 
> > > > Or might be time to do this block/inline specific sub-class.
> > > 
> > > yes, I was thinking about that as well. Here are 4 options:
> > > 
> > > 1) Make NGInlineLayoutAlgorithm to inherit NGBlockLayoutAlgorithm. That's
> > > because NGInlineLayoutAlgorithm produces a block fragment as as result.
> > > 
> > > 2) (SELECTED) Leave PositionPendingFloats in NGLayoutAlgorithm base class
> for
> > > now but have an annotation that it should be only used by
> > > NG{Block|Inline}Algorithms. Later we can decide what to do with them
> > > 
> > > 3) Make PositionPendingFloats static. But that will make
> PositionPendingFloats
> > > usage not very convenient. 
> > > 
> > > 4) Create an interim base class for Block/Inline algorithms.
> > 
> > My preferred option here would be (4) in a follow up patch. We'll need to be
> > very principled about only simple methods in the base class.
> 
> ok, lets choose a name for that class then. NGBaseBlockLayoutAlgorithm ?

made PositionPendingFloats to be a static method, same as
MaybeUpdateFragmentBfcOffset.

[Gleb Lanbin, 2017-04-19 19:57:04]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 19:57:57]

Dry run: 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, 2017-04-19 20:03:37]

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

[commit-bot: I haz the power, 2017-04-19 20:03:38]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Gleb Lanbin, 2017-04-19 20:23:16]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 20:23:49]

Dry run: 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, 2017-04-19 22:03:54]

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

[commit-bot: I haz the power, 2017-04-19 22:03:55]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Gleb Lanbin, 2017-04-20 01:36:20]

The CQ bit was checked by glebl@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-20 01:37:04]

Dry run: 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, 2017-04-20 03:37:45]

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

[commit-bot: I haz the power, 2017-04-20 03:37:46]

Dry run: This issue passed the CQ dry run.

[Gleb Lanbin, 2017-04-20 04:34:23]

The CQ bit was checked by glebl@chromium.org

[Gleb Lanbin, 2017-04-20 04:34:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
ikilpatrick@chromium.org
Link to the patchset: https://codereview.chromium.org/2816933003/#ps150001
(title: "fix block-formatting-contexts-{005|007}")

[commit-bot: I haz the power, 2017-04-20 04:34:47]

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, 2017-04-20 04:39:04]

CQ is committing da patch.

Bot data: {"patchset_id": 150001, "attempt_start_ts": 1492662863844820,
"parent_rev": "2ecea20b01bdccc4f80893e5e14955bad1e9a554", "commit_rev":
"c873e8003e60b30ff8bd65fd345b70faf77cd700"}

[commit-bot: I haz the power, 2017-04-20 04:39:38]

Description was changed from

==========
Use Layout Opportunity Iterator to position new FC blocks.

This patch fixes the use case when we need to use Layout Opportunity
Iterator to position a block that establishes a new formatting context.

BUG=635619
TEST=NGBlockLayoutAlgorithmTest.NewFcBlockWithAdjoiningFloatCollapsesMargins
==========

to

==========
Use Layout Opportunity Iterator to position new FC blocks.

This patch fixes the use case when we need to use Layout Opportunity
Iterator to position a block that establishes a new formatting context.

BUG=635619
TEST=NGBlockLayoutAlgorithmTest.NewFcBlockWithAdjoiningFloatCollapsesMargins

Review-Url: https://codereview.chromium.org/2816933003
Cr-Commit-Position: refs/heads/master@{#465899}
Committed:
https://chromium.googlesource.com/chromium/src/+/c873e8003e60b30ff8bd65fd345b...
==========

[commit-bot: I haz the power, 2017-04-20 04:39:39]

Committed patchset #8 (id:150001) as
https://chromium.googlesource.com/chromium/src/+/c873e8003e60b30ff8bd65fd345b...