Set m_{width,height}AvailableToChildrenChanged when scrollbars appear

third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012 Apple Inc. All rights reserved.
  *
  * Portions are Copyright (C) 1998 Netscape Communications Corporation.
  *
  * Other contributors:
  *   Robert O'Callahan <roc+@cs.cmu.edu>
  *   David Baron <dbaron@fas.harvard.edu>
  *   Christian Biesinger <cbiesinger@gmail.com>
  *   Randall Jesup <rjesup@wgate.com>
@@ skipping 664 matching lines @@
         // Force an update since we know the scrollbars have changed things.
         if (box().document().hasAnnotatedRegions())
             box().document().setAnnotatedRegionsDirty(true);
 
         // Our proprietary overflow: overlay value doesn't trigger a layout.
         if ((horizontalScrollBarChanged && box().style()->overflowX() != OverflowOverlay) || (verticalScrollBarChanged && box().style()->overflowY() != OverflowOverlay)) {
             if (!m_inOverflowRelayout) {
                 m_inOverflowRelayout = true;
                 if (delayedLayoutScope) {
                     delayedLayoutScope->setNeedsLayout(&box(), LayoutInvalidationReason::ScrollbarChanged);
+                    // Since we can't pass true to layoutBlock to force relaying out the children, mark them explicitly.
+                    // They do have to be laid out again because their available width has now changed.
+                    for (LayoutObject* child = box().slowFirstChild(); child; child = child->nextSibling())
+                        delayedLayoutScope->setNeedsLayout(child, LayoutInvalidationReason::ScrollbarChanged);

[mstensho (USE GERRIT), 2016/03/17 19:57:06]

Aren't you going to miss marking out-of-flow positioned descendants that aren't
direct children?

[cbiesinger, 2016/03/17 20:03:03]

Um, good question. I'm not familiar with that part of layout actually, for which
cases does that happen?

Are you suggesting I also iterate over positionedObjects()?

(fixed the comments on the testcase)

[mstensho (USE GERRIT), 2016/03/17 20:24:07]

Maybe this (based on the test already in this CL)?

    <div id="root" class="root" style="position:relative;">
      <div>
        <div id="history" style="position:absolute;"></div>
      </div>
    </div>

Actually, we may have to wrap the abspos harder:

    <div id="root" class="root" style="position:relative;">
      <div style="width:100px;">
        <div style="width:100px;">
          <div id="history" style="position:absolute;"></div>
        </div>
      </div>
    </div>

I don't remember exactly how Blink decides to descend into children that aren't
marked for layout, when the parent is. Nothing should be able to punch through
two walls of fixed width, though. :)
That should work. Maybe better introduce a method in LayoutBlock to handle all
this mark-children-and-some-other-descendants-for-layout-as-well stuff, then?

                     didMarkForDelayedLayout = true;
                 } else {
                     SubtreeLayoutScope layoutScope(box());
                     layoutScope.setNeedsLayout(&box(), LayoutInvalidationReason::ScrollbarChanged);
                     if (box().isLayoutBlock()) {
                         LayoutBlock& block = toLayoutBlock(box());
                         block.scrollbarsChanged(horizontalScrollBarChanged, verticalScrollBarChanged);
                         block.layoutBlock(true);
                     } else {
                         box().layout();
@@ skipping 888 matching lines @@
 }
 
 DEFINE_TRACE(PaintLayerScrollableArea::ScrollbarManager)
 {
     visitor->trace(m_scrollableArea);
     visitor->trace(m_hBar);
     visitor->trace(m_vBar);
 }
 
 } // namespace blink