Fix incorrectly calculated content_size for fragments that create new FC

third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc

Index: third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
diff --git a/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc b/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
index c56b00f30e04912ed9ef24b3e2aa87c185af54b2..cf5acdafe9d4cd71ed7852d0a562b042b482bd13 100644
--- a/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
+++ b/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
@@ -104,6 +104,14 @@ bool NGBlockLayoutAlgorithm::Layout(const NGConstraintSpace* constraint_space,
     }
     case kStateFinalize: {
       content_size_ += border_and_padding_.block_end;
+      // Margins of the newly established formatting context do not participate
+      // in Collapsing Margins and therefore need to be added to the current
+      // content_size.
+      if (constraint_space->IsNewFormattingContext()) {
+        content_size_ += builder_->MarginStrut().BlockEndSum();

[cbiesinger, 2016/10/03 19:58:27]

That does not look right, shouldn't this be handled by the parent? We don't add
margin-start to content_size either.

[Gleb Lanbin, 2016/10/04 14:47:49]

the logic is correct, I double verified it with Ian. I moved this part to
CollapseMargins method. Hope it looks better now.

+        builder_->ClearMarginStrut();
+      }
+
       // Recompute the block-axis size now that we know our content size.
       LayoutUnit block_size = computeBlockSizeForFragment(
           *constraint_space, *style_, content_size_);