[LayoutNG] Pull out of flow candidate loop into out of flow layout part.

third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h

Index: third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h
diff --git a/third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h b/third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h
index 0391cb1b74a359437ac3d93c94f7772c488d17cf..339429220511a07399dceb5d23d21381d1c8810e 100644
--- a/third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h
+++ b/third_party/WebKit/Source/core/layout/ng/ng_fragment_builder.h
@@ -52,26 +52,13 @@ class CORE_EXPORT NGFragmentBuilder final
   //     builder->AddChild(fragment)
   // end
   //
-  // Part 2: layout algorithm positions out-of-flow descendants.
-  //
   // builder->SetInlineSize/SetBlockSize
-  // builder->GetAndClearOutOfFlowDescendantCandidates(oof_candidates);
-  // NGOutOfFlowLayoutPart out_of_flow_layout(container_style,
-  //                                          builder->Size());
-  // while (oof_candidates.size() > 0)
-  // {
-  //   candidate = oof_candidates.shift();
-  //   if (IsContainingBlockForAbsoluteChild(style, candidate_style)) {
-  //     NGFragmentBase* fragment;
-  //     NGLogicalOffset* fragment_offset;
-  //     out_of_flow_layout.Layout(candidate, &fragment, &offset);
-  //     builder->AddChild(fragment);
-  //     builder->GetAndClearOutOfFlowDescendantCandidates(child_oof_candidates);
-  //     oof_candidates.prepend(child_oof_candidates);

[ikilpatrick, 2017/01/20 23:48:30]

So the code in ng_block_algorithm never did this, is this needed?

[atotic, 2017/01/23 07:37:56]

No. Good catch. This was code that was trying to solve the problem of
fixed position LegacyLayout being positioned inside an oof_descendant.

It turns out this is not a problem because the contaner for LegacyLayout
will always be either a descendant of current element (for position:absolute
legacy)
or #document (for position:fixed legacy). Both of those cases are already
handled.

[ikilpatrick, 2017/01/24 19:11:32]

Is there any reason for the GetAndClear method now then?

[atotic, 2017/01/24 20:48:34]

Miscommunication: I was referring to the last two lines of the original comment:
//     builder->GetAndClearOutOfFlowDescendantCandidates(child_oof_candidates);
//     oof_candidates.prepend(child_oof_candidates);

Here we were getting oof_candidates at the end of every loop iteration.
This turned out to be unnecessary.

The rest of the sample code still stands, and
GetAndClearOutOfFlowDescendantCandidates
is called at the beginning.

-  //   } else {
-  //     builder->AddOutOfFlowDescendant();
-  //   }
-  // }
+  //
+  // Part 2: Out-of-flow layout part positions out-of-flow descendants.
+  //
+  // NGOutOfFlowLayoutPart(container_style, builder).Run();
+  //
+  // See layout part for builder interaction.
   NGFragmentBuilder& AddOutOfFlowChildCandidate(NGBlockNode*, NGLogicalOffset);
 
   void GetAndClearOutOfFlowDescendantCandidates(WeakBoxList*,