Drag-and-drop: updateDragCursor

content/browser/renderer_host/render_widget_host_delegate.h

 // Copyright (c) 2012 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 CONTENT_BROWSER_RENDERER_HOST_RENDER_WIDGET_HOST_DELEGATE_H_
 #define CONTENT_BROWSER_RENDERER_HOST_RENDER_WIDGET_HOST_DELEGATE_H_
 
 #include <stdint.h>
 
 #include <vector>
@@ skipping 15 matching lines @@
 
 namespace gfx {
 class Point;
 class Rect;
 class Size;
 }
 
 namespace content {
 
 class BrowserAccessibilityManager;
+class RenderWidgetHost;
 class RenderWidgetHostImpl;
 class RenderWidgetHostInputEventRouter;
 class RenderViewHostDelegateView;
 class TextInputManager;
 struct ScreenInfo;
 struct NativeWebKeyboardEvent;
 
 //
 // RenderWidgetHostDelegate
 //
@@ skipping 163 matching lines @@
   virtual bool IsHidden();
 
   // Returns the associated RenderViewHostDelegateView*, if possible.
   virtual RenderViewHostDelegateView* GetDelegateView();
 
   // Returns the current Flash fullscreen RenderWidgetHostImpl if any. This is
   // not intended for use with other types of fullscreen, such as HTML
   // fullscreen, and will return nullptr for those cases.
   virtual RenderWidgetHostImpl* GetFullscreenRenderWidgetHost() const;
 
+  // This is used to give the delegate a chance to filter IPC messages.
+  virtual bool OnMessageReceived(RenderWidgetHost* render_widget_host,
+                                 const IPC::Message& message);

[ncarter (slow), 2016/11/14 20:23:45]

I think it's probably better to add 1 call to RenderWidgetHostDelegate for each
message we need to migrate. Basically, handle the message in the RWH message
dispatcher, and forward it to the webcontents via a virtual method in
RenderWidgetHostDelegate.

There's two reasons why I think this. First, the OnMessageReceived pattern is
not mojo compatible (in mojo we won't be able to pass around a polymorphic
IPC::Message-like object). Since we'll have to eventually move to
one-delegate-method-per-IPC anyway, we might as well do it now.

Second, I can't easily assess the risk of forwarding all widget messages from
RenderWidget to WebContents. For popup and fullscreen widgets, it's possible
that this will have unintended consequences; if there's a message that
WebContents handles on behalf of its RenderViewHosts, that Widget happens also
to send/handle, and now WebContents will start handling them.

[paulmeyer, 2016/11/14 22:03:53]

Okay, that sounds very reasonable. Done.

+
  protected:
   virtual ~RenderWidgetHostDelegate() {}
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_RENDERER_HOST_RENDER_WIDGET_HOST_DELEGATE_H_