Remove FrameViewBase as base class of PluginView.

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

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #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*);
 
   ~RemoteFrameView() override;
 
   bool IsRemoteFrameView() const override { return true; }
   void SetParent(FrameViewBase*) override;
 
   RemoteFrame& GetFrame() const {
     ASSERT(remote_frame_);
     return *remote_frame_;
   }
 
   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;
 
   DECLARE_VIRTUAL_TRACE();
 
  private:
   explicit RemoteFrameView(RemoteFrame*);
 
   void UpdateRemoteViewportIntersection();
 
   // The properties and handling of the cycle between RemoteFrame
   // and its RemoteFrameView corresponds to that between LocalFrame
   // and FrameView. Please see the FrameView::m_frame comment for
   // details.
   Member<RemoteFrame> remote_frame_;
 
   IntRect last_viewport_intersection_;
 };
 
 DEFINE_TYPE_CASTS(RemoteFrameView,
                   FrameViewBase,
                   frameViewBase,
                   frameViewBase->IsRemoteFrameView(),
                   frameViewBase.IsRemoteFrameView());
 
 }  // namespace blink
 
 #endif  // RemoteFrameView_h