[css-grid] Clearing override sizes before running grid's layout logic.

third_party/WebKit/Source/core/frame/FrameView.cpp

 /*
  * Copyright (C) 1998, 1999 Torben Weis <weis@kde.org>
  *                     1999 Lars Knoll <knoll@kde.org>
  *                     1999 Antti Koivisto <koivisto@kde.org>
  *                     2000 Dirk Mueller <mueller@kde.org>
  * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved.
  *           (C) 2006 Graham Dennis (graham.dennis@gmail.com)
  *           (C) 2006 Alexey Proskuryakov (ap@nypop.com)
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
@@ skipping 1870 matching lines @@
     if (LayoutBlock* cb = root.containingBlock()) {
         if (cb->needsLayout() && cb->isLayoutBlockFlow())
             toLayoutBlockFlow(cb)->removeFloatingObjects();
     }
 }
 
 void FrameView::layoutOrthogonalWritingModeRoots()
 {
     for (auto& root : m_orthogonalWritingModeRootList.ordered()) {
         ASSERT(root->isBox() && toLayoutBox(*root).isOrthogonalWritingModeRoot());
+        if (toLayoutBox(*root).hasContainingBlockOverrideSize() || toLayoutBox(*root).hasOverrideSize()) {

[cbiesinger, 2016/09/26 11:48:32]

Hmm, so I understand why you're doing this but I think there are two (related)
problems:
- For each layout pass, you force-layout all orthogonal roots whether they need
to be laid out or not. Shouldn't you check .needsLayout() ||
root->parent().needsLayout()?
- You lay out the child but the parent may not be marked for layout. That means
that there may not be a full grid layout to lay out the child at the correct
size, and the child may remain at the incorrect size! (The size without the
override applied)

[jfernandez, 2016/09/26 13:38:02]

For the case I'm trying to solve is not enough to check for needsLayout, since
this
re-layout is triggered by scrollbar changes which set grid container's preferred
width
as dirty; grid container will be marked for layout later.
Yeah, as I said, for the scenario I'm trying to solve the container will be
marked
for layout, but it's true that this may not be the case in other situations.
I'll have to
think about it.

+            toLayoutBox(*root).clearOverrideSize();
+            toLayoutBox(*root).clearContainingBlockOverrideSize();
+            root->setNeedsLayout(LayoutInvalidationReason::SizeChanged);
+        }
         if (!root->needsLayout()
             || root->isOutOfFlowPositioned()
             || root->isColumnSpanAll()
             || !root->styleRef().logicalHeight().isIntrinsicOrAuto()) {
             continue;
         }
 
         removeFloatingObjectsForSubtreeRoot(*root);
         layoutFromRootObject(*root);
     }
@@ skipping 2500 matching lines @@
 }
 
 bool FrameView::canThrottleRendering() const
 {
     if (!RuntimeEnabledFeatures::renderingPipelineThrottlingEnabled())
         return false;
     return m_subtreeThrottled || (m_hiddenForThrottling && m_crossOriginForThrottling);
 }
 
 } // namespace blink