Clear the owner element's widget in Document::shutdown().

FrameView::dispose() doesn't guarantee that the owner's widget is cleared
and this could be problematic when it's overwritten in
LocalFrame::createView() a short time later.

BUG=673170

Review-Url: https://codereview.chromium.org/2563313002
Cr-Commit-Position: refs/heads/master@{#438977}

third_party/WebKit/Source/core/dom/Document.cpp

@@ -2405,6 +2405,15 @@ void Document::shutdown() {
   ScriptForbiddenScope forbidScript;
 
   view()->dispose();
+
+  // If the widget of the document's frame owner doesn't match view() then
+  // FrameView::dispose() didn't clear the owner's widget. If we don't clear it
+  // here, it may be clobbered later in LocalFrame::createView(). See also
+  // https://crbug.com/673170 and the comment in FrameView::dispose().
+  HTMLFrameOwnerElement* ownerElement = m_frame->deprecatedLocalOwner();
+  if (ownerElement)
+    ownerElement->setWidget(nullptr);
+
   m_markers->prepareForDestruction();
 
   m_lifecycle.advanceTo(DocumentLifecycle::Stopping);

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

@@ -350,8 +350,11 @@ void FrameView::dispose() {
 
   // FIXME: Do we need to do something here for OOPI?
   HTMLFrameOwnerElement* ownerElement = m_frame->deprecatedLocalOwner();
-  // TODO(dcheng): It seems buggy that we can have an owner element that
-  // points to another Widget.
+  // TODO(dcheng): It seems buggy that we can have an owner element that points
+  // to another Widget. This can happen when a plugin element loads a frame
+  // (widget A of type FrameView) and then loads a plugin (widget B of type
+  // WebPluginContainerImpl). In this case, the frame's view is A and the frame
+  // element's owned widget is B. See https://crbug.com/673170 for an example.
   if (ownerElement && ownerElement->ownedWidget() == this)
     ownerElement->setWidget(nullptr);