Fix when orthogonal writing mode roots have floating siblings

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 1761 matching lines @@
 void FrameView::layoutOrthogonalWritingModeRoots()
 {
     for (auto& root : m_orthogonalWritingModeRootList.ordered()) {
         ASSERT(root->isBox() && toLayoutBox(*root).isOrthogonalWritingModeRoot());
         if (!root->needsLayout()
             || root->isOutOfFlowPositioned()
             || root->isColumnSpanAll()
             || !root->styleRef().logicalHeight().isIntrinsicOrAuto()) {
             continue;
         }
-        LayoutState layoutState(*root);
-        root->layout();
+
+        // Floating objects are cached and re-created when containing block
+        // layouts. At this point, it may contain old or even detached objects.
+        if (LayoutBlock* cb = root->containingBlock()) {
+            if (cb->isLayoutBlockFlow())
+                toLayoutBlockFlow(cb)->removeFloatingObjects();

[rhogan, 2016/06/06 09:41:02]

Per my note on the bug, we should skip orthogonal layout on the child in this
situation and let main layout look after it.

Removing floats is expensive. (Also, you would only want to do it when cb
needsLayout().)

The thing causing us a headache here is that the writing mode on both child and
container have been made orthogonal but neither have had a layout in their new
writing modes yet. Detecting this situation in
layoutOrthogonalWritingModeRoots() and skipping orthogonal layout on affected
roots would be ideal - they will get relayout in main layout anyway so it will
be less work overall too.

Can you look at what would be involved in skipping orthogonal layout on the
child? That is definitely the better solution here.

+        }
+
+        layoutFromRootObject(*root);
     }
 }
 
 void FrameView::scheduleRelayout()
 {
     ASSERT(m_frame->view() == this);
     RELEASE_ASSERT(!isInPerformLayout());
 
     if (!m_layoutSchedulingEnabled)
         return;
@@ skipping 2321 matching lines @@
     return m_subtreeThrottled || (m_hiddenForThrottling && m_crossOriginForThrottling);
 }
 
 LayoutBox& FrameView::boxForScrollControlPaintInvalidation() const
 {
     ASSERT(!layoutViewItem().isNull());
     return *layoutView();
 }
 
 } // namespace blink