Remove FrameViewBase as base class of RemoteFrameView.

third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h

Index: third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
diff --git a/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h b/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
index c31ab53ff7e85eb90f1be7f79a8832b260de0151..9cb154427fb56f397c53e0d0076b7d07cff818c5 100644
--- a/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
+++ b/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h
@@ -37,7 +37,6 @@ namespace blink {
 class ExceptionState;
 class Frame;
 class FrameOrPlugin;
-class FrameViewBase;
 class LayoutPart;
 
 class CORE_EXPORT HTMLFrameOwnerElement : public HTMLElement,
@@ -62,9 +61,9 @@ class CORE_EXPORT HTMLFrameOwnerElement : public HTMLElement,
   virtual bool LoadedNonEmptyDocument() const { return false; }
   virtual void DidLoadNonEmptyDocument() {}
 
-  void SetWidget(FrameViewBase*);
-  FrameViewBase* ReleaseWidget();
-  FrameViewBase* OwnedWidget() const;
+  void SetWidget(FrameOrPlugin*);

[joelhockey, 2017/05/01 23:04:35]

Widget type has changed from platform/FrameViewBase to core/frame/FrameOrPlugin.
I still plan to change the name of this method to something other than 'Widget'
once I think of something better.  Right now 'FrameOrPlugin' is the leading
candidate.

Previously I moved PluginView to be stored on HTMLPlugInElement.  I have now
moved it back to be part of the single 'widget_' field in HTMLFrameOwnerElement.
 Having the single field simplifies the overall code, particularly the attach
and disposal.

I still make a distinction in LayoutPart class where callers can request only
the PluginView, or only the FrameView, or for FrameOrPlugin which may be any of
[Frame|RemoteFrame|Plugin]View.

[dcheng, 2017/05/09 07:50:51]

FrameOrPlugin doesn't really help readers understand the purpose of the class
though. Readers only know that it has something do with frames or plugins, but
not really what. We probably should have just left it named "Widget" until we
had a clearer picture of what would be left on FrameOrPlugin, but that ship has
already sailed.

My personal suggestion is something along the lines of of
EmbeddedObject/EmbeddedObjectHost/EmbeddedObjectController, but this isn't great
for several reasons:
- It's kind of confusing since we also have LayoutEmbeddedObject. Maybe the Host
or Controller suffix will help disambiguate.
- At the same time, just adding Host or Controller doesn't address my earlier
question of "what does this class do". But calling it EmbeddedObject makes it a
bit clearer what types of objects it's intended for... I think.
- something else?

At the same time, it's a bit more descriptive than Widget, and more accurate
once Scrollbar is no longer in the picture...

All this is a long-winded way of saying: let's leave the names for now, finish
the code cleanup, and then rename classes as appropriate.

[joelhockey, 2017/05/10 02:35:43]

agree.  If I knew before what I know now, I would have left the Widget class
named as Widget since it is to be deleted in any case.

[szager1, 2017/05/10 09:41:03]

My $.02: Widget would still have been a bad name, because it's still way too
generic.

I would opt for something like EmbeddedContentView.  "EmbeddedContent" because
it's embedded content; and "View" for the same reason we use the name FrameView,
i.e., because it's the visible manifestation of a Frame.  Similarly, a
PluginView is the visible manifestation of a plugin, and an EmbeddedContentView
is the visible manifestation of embedded content.

+  FrameOrPlugin* ReleaseWidget();
+  FrameOrPlugin* OwnedWidget() const { return widget_; }
 
   class UpdateSuspendScope {
     STACK_ALLOCATED();
@@ -141,7 +140,7 @@ class CORE_EXPORT HTMLFrameOwnerElement : public HTMLElement,
   }
 
   Member<Frame> content_frame_;
-  Member<FrameViewBase> widget_;
+  Member<FrameOrPlugin> widget_;
   SandboxFlags sandbox_flags_;
 
   WebParsedFeaturePolicy container_policy_;