Fix when orthogonal writing mode roots have floating siblings

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

Index: third_party/WebKit/Source/core/frame/FrameView.cpp
diff --git a/third_party/WebKit/Source/core/frame/FrameView.cpp b/third_party/WebKit/Source/core/frame/FrameView.cpp
index f881a6042a874b94b9ee6295408a6c25b0d0dcb8..a68a45dd0703650b600c68d13f64ddfbab9aa63e 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -1779,8 +1779,15 @@ void FrameView::layoutOrthogonalWritingModeRoots()
             || !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);
     }
 }