Initialize child framesets when they become part of the parent frameset grid.

third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp

Index: third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp
diff --git a/third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp b/third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp
index 426970e19eeabccc72492a1cc540ebfb0a601524..be3aa68e1c81eb1b2fbf8b213ba43ab9999d977e 100644
--- a/third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp
+++ b/third_party/WebKit/Source/core/layout/LayoutFrameSet.cpp
@@ -418,8 +418,11 @@ void LayoutFrameSet::positionFrames()
             child->setLocation(position);
             size.setWidth(LayoutUnit(m_cols.m_sizes[c]));
 
-            // has to be resized and itself resize its contents
-            if (size != child->size()) {
+            // If we have a new size, we need to resize and layout the child. If the size is 0x0 we
+            // also need to lay out, since this may mean that we're dealing with a child frameset
+            // that wasn't previously initialized properly, because it was previously hidden, but
+            // no longer is, because rows * cols may have increased.
+            if (size != child->size() || size.isEmpty()) {

[mstensho (USE GERRIT), 2016/04/01 12:21:47]

This is the simplest fix that I can think of. A safer but slightly uglier fix
could be to condition the child on being a LayoutFrameSet without rows() and
cols() initialized. But hopefully what I'm doing here doesn't have any unwanted
side-effects (performance-wise or other-wise)?

                 child->setSize(size);
                 child->setNeedsLayoutAndFullPaintInvalidation(LayoutInvalidationReason::SizeChanged);
                 child->layout();