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

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

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NGFragmentBuilder_h
 #define NGFragmentBuilder_h
 
 #include "core/layout/ng/ng_physical_fragment.h"
 #include "core/layout/ng/ng_units.h"
 
@@ skipping 34 matching lines @@
   //   are stored inside builder.
   //
   // for (child : children)
   //   if (child->position == (Absolute or Fixed))
   //     builder->AddOutOfFlowChildCandidate(child);
   //   else
   //     fragment = child->Layout()
   //     builder->AddChild(fragment)
   // end
   //
-  // Part 2: layout algorithm positions out-of-flow descendants.
+  // builder->SetInlineSize/SetBlockSize
   //
-  // 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*,
                                                 Vector<NGStaticPosition>*);
 
   NGFragmentBuilder& AddOutOfFlowDescendant(NGBlockNode*,
                                             const NGStaticPosition&);
 
   void SetBreakToken(NGBreakToken* token) {
     DCHECK(!break_token_);
@@ skipping 52 matching lines @@
 
   WeakBoxList out_of_flow_descendants_;
   Vector<NGStaticPosition> out_of_flow_positions_;
 
   Member<NGBreakToken> break_token_;
 };
 
 }  // namespace blink
 
 #endif  // NGFragmentBuilder