Fix unscrollable scrollers after closing a <dialog>.

third_party/WebKit/Source/core/html/HTMLDialogElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp b/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
index 9edc5883e4ea38e02f6a61618fe0434fdac93113..e6e7b474ed34c4ac65514c55d340b073d18e6c02 100644
--- a/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
@@ -33,6 +33,7 @@
 #include "core/frame/FrameView.h"
 #include "core/frame/UseCounter.h"
 #include "core/html/HTMLFormControlElement.h"
+#include "core/layout/LayoutView.h"
 #include "core/style/ComputedStyle.h"
 
 namespace blink {
@@ -116,8 +117,15 @@ void HTMLDialogElement::closeDialog(const String& returnValue) {
 
   HTMLDialogElement* activeModalDialog = document().activeModalDialog();
   document().removeFromTopLayer(this);
-  if (activeModalDialog == this)
+  if (activeModalDialog == this) {
     inertSubtreesChanged(document());
+    // Any scrollers that were laid out when we were shown need to be laid out
+    // again now to keep FrameView::m_scrollableAreas up to date. To that end,
+    // force normal layout instead of simplified layout on the document.
+    // See crbug.com/633520 for details.
+    document().layoutView()->setNeedsLayout(

[esprehn, 2016/10/15 08:38:46]

This should be in the top layer management code, not inside dialog. Anything
inside too layer will manifest similar bugs since they become kids of the
LayoutView. It's also very strange for the DOM to explicitly  mark layout dirty,
that generally means something is broken at a deeper level in the system.

+        LayoutInvalidationReason::ChildChanged);
+  }
 
   if (!returnValue.isNull())
     m_returnValue = returnValue;