Remove FrameViewBase as base class of PluginView.

third_party/WebKit/Source/core/frame/RemoteFrameView.h

Index: third_party/WebKit/Source/core/frame/RemoteFrameView.h
diff --git a/third_party/WebKit/Source/core/frame/RemoteFrameView.h b/third_party/WebKit/Source/core/frame/RemoteFrameView.h
index 3a1f93d5d18debe5d46bcccdd143ac20389d5cbe..886ec9a3d63e85ca2d5dee5f8dcd5e6df63e1fa9 100644
--- a/third_party/WebKit/Source/core/frame/RemoteFrameView.h
+++ b/third_party/WebKit/Source/core/frame/RemoteFrameView.h
@@ -5,15 +5,20 @@
 #ifndef RemoteFrameView_h
 #define RemoteFrameView_h
 
+#include "core/frame/FrameOrPlugin.h"
 #include "platform/FrameViewBase.h"
 #include "platform/geometry/IntRect.h"
 #include "platform/heap/Handle.h"
 
 namespace blink {
 
+class CullRect;
+class GraphicsContext;
 class RemoteFrame;
 
-class RemoteFrameView final : public FrameViewBase {
+class RemoteFrameView final : public FrameViewBase, public FrameOrPlugin {
+  USING_GARBAGE_COLLECTED_MIXIN(RemoteFrameView);
+
  public:
   static RemoteFrameView* Create(RemoteFrame*);
 
@@ -30,8 +35,12 @@ class RemoteFrameView final : public FrameViewBase {
   void Dispose() override;
   // Override to notify remote frame that its viewport size has changed.
   void FrameRectsChanged() override;
-  void InvalidateRect(const IntRect&) override;
+  void InvalidateRect(const IntRect&);
   void SetFrameRect(const IntRect&) override;
+  const IntRect& FrameRect() const override {
+    return FrameViewBase::FrameRect();
+  }
+  void Paint(GraphicsContext&, const CullRect&) const override {}

[dcheng, 2017/04/17 21:09:04]

This is a bit tricky, because this overrides methods from both FrameViewBase
*and* FrameOrPlugin. It might be worth calling this out, until we remove
FrameViewBase?

I would suggest that this means FrameOrPlugin should just be a base of
FrameViewBase: I don't think this makes it harder to remove FrameViewBase in the
long run, and it prevents the short-term awkwardness of having parallel virtual
dispatch hierarchies.

It also makes it clear which FrameViewBase methods are left to finish moving out
before we can remove it altogether. WDYT?

[joelhockey, 2017/04/18 00:42:41]

I would rather have FrameOrPlugin class be in core/frame rather than platform
(where FrameViewBase is).  I have been able to easily remove Paint, Show, Hide
from FrameViewBase right now which means less parallel virtual dispatch.  It is
only SetFrameRect, FrameRect, and Dispose that now exist in both.  I could
remove them in this CL, but it is a little bit involved, so I would rather do it
in a separate CL.

[dcheng, 2017/04/18 00:56:31]

Hmm. I guess this is fine for now given the reduced duplication, and that it's
only temporary.

(My one thought is it's a bit funny for core/plugins to implement something in
core/frame, but it seems limited enough that it's probably OK)

   void Hide() override;
   void Show() override;
   void SetParentVisible(bool) override;