Move plugins to be stored in HTMLPlugInElement.

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

Index: third_party/WebKit/Source/core/dom/Document.cpp
diff --git a/third_party/WebKit/Source/core/dom/Document.cpp b/third_party/WebKit/Source/core/dom/Document.cpp
index 9e41f765649fb17d020fe6f900fca37b8307dda5..0cbe2398d46789970aa9b47754bc01859feb26e9 100644
--- a/third_party/WebKit/Source/core/dom/Document.cpp
+++ b/third_party/WebKit/Source/core/dom/Document.cpp
@@ -164,6 +164,7 @@
 #include "core/html/HTMLInputElement.h"
 #include "core/html/HTMLLinkElement.h"
 #include "core/html/HTMLMetaElement.h"
+#include "core/html/HTMLPlugInElement.h"
 #include "core/html/HTMLScriptElement.h"
 #include "core/html/HTMLTemplateElement.h"
 #include "core/html/HTMLTitleElement.h"
@@ -367,6 +368,13 @@ static inline bool isValidNamePart(UChar32 c) {
 }
 
 static FrameViewBase* frameViewBaseForElement(const Element& focusedElement) {
+  // Return either plugin or frame.
+  // TODO(joelhockey): FrameViewBase class will soon be removed.  It will be
+  // replaced with Focusable ABC that FrameView and PluginView will implement
+  // and this method will return Focusable.
+  if (isHTMLPlugInElement(focusedElement))
+    return toHTMLPlugInElement(focusedElement).plugin();

[dcheng, 2017/04/05 09:12:24]

Btw, I would suggest just changing 381 to use pluginOrFrame() and remove this
for now.

If/when we get around to changing pluginOrFrame(), we'll have a natural way of
addressing the issue here then as well

[joelhockey, 2017/04/05 22:10:31]

I'll stick with this for right now in the hope of landing this quickly.  But
I've found out from my investigations yesterday that only plugin is relevant
here in the calls to setFocus, and this code will go away when I use the
dispatchBlur/dispatchFocus directly on HTMLPlugInElement.

+
   LayoutObject* layoutObject = focusedElement.layoutObject();
   if (!layoutObject || !layoutObject->isLayoutPart())
     return 0;