Implement Mac Pop-up Dictionary for OOPIF.

content/renderer/render_widget.cc

Index: content/renderer/render_widget.cc
diff --git a/content/renderer/render_widget.cc b/content/renderer/render_widget.cc
index cb2afbcc623807384a97bb66e7a6fb376251af6d..6930cc8346e8d0700973b798ab1018232d563eee 100644
--- a/content/renderer/render_widget.cc
+++ b/content/renderer/render_widget.cc
@@ -52,6 +52,7 @@
 #include "content/renderer/render_widget_owner_delegate.h"
 #include "content/renderer/renderer_blink_platform_impl.h"
 #include "content/renderer/resizing_mode_selector.h"
+#include "ipc/ipc_message_start.h"
 #include "ipc/ipc_sync_message.h"
 #include "skia/ext/platform_canvas.h"
 #include "third_party/WebKit/public/platform/WebCursorInfo.h"
@@ -464,6 +465,12 @@ void RenderWidget::OnShowHostContextMenu(ContextMenuParams* params) {
 }
 
 bool RenderWidget::OnMessageReceived(const IPC::Message& message) {
+#if defined(OS_MACOSX)
+  if (IPC_MESSAGE_CLASS(message) == TextInputClientMsgStart) {
+    FOR_EACH_OBSERVER(RenderFrameImpl, render_frames_,
+                      OnTextInputClientMessageReceived(this, message));

[Charlie Reis, 2016/08/31 22:50:03]

Why is this needed?  (Forwarding IPCs can be risky, vs routing them to the right
place to begin with.)  Are we supposed to continue below afterward, or return
early?

[EhsanK, 2016/09/01 21:58:37]

All such IPCs are triggered by RenderWidgetHostViewCocoa and sent through
RenderWidgetHost. I see two options here:
Option-1) Send the IPC to RenderWidget (as it is right now) and handle it here.
Unfortunately, for reasons such as accessing focused plugin and also
focusedFrame we cannot have RenderWidget handle this now. The issues are
 1-1) WebViewImpl is a WebWidget but inheritance is protected. So later in
TextInputClientObserver we cannot down cast to WebViewImpl. Right now I am
passing both WebWidget and WebView to WebSubstringUtil methods which is ugly as
well.
  1-2) We need focused plugin. This could be resolved though if we don't have
issues with 1-1). I can search the frame tree and cast frames to RenderFrame the
same way RenderViewImpl::GetFocusedPepperPlugin() works now.

Resolving 1-1) and 1-2) will enable us to move TextInputClientObserver to
RenderWidget and avoid this observer call (handle IPC right here).

Option-2) Send the IPC to RenderFrameImpl. But this will be uglier (IMO) on the
browser side. We will have to get from RenderWidgetHost to RenderFrame to send
the IPC. Also, some parts of TextInputClientMac relate to IME (dictionary pop-up
is some sort of input I guess).
My suggestion is proceeding with Option-1 until we can give the ownership of
TextInputClientObserver to RenderWidget. Maybe this becomes a possibility (minus
the plugin access problem) when Lucas's patch lands:
https://codereview.chromium.org/2288313002/

[Charlie Reis, 2016/09/02 21:38:17]

Hmm.  If the intention is to move TextInputClientObserver to RenderWidget, then
I suppose we can keep having the IPCs sent here.

How many messages are we talking about?  I'm wondering if it's clearer to have
IPC handlers for them here in RenderWidget and just have them call a
corresponding method on the local root RenderFrame for now (which passes it on
to the TextInputClientObserver).

If there's several messages, then I suppose we can keep this approach but add a
comment explaining why we have it.  If we do stick with this approach, is there
a way to send it to just the local root RenderFrame and not all RenderFrames of
the widget?  And shouldn't we be returning early?

+  }
+#endif
   if (mouse_lock_dispatcher_ &&
       mouse_lock_dispatcher_->OnMessageReceived(message))
     return true;