Move find-in-page code from RenderView to RenderFrame.

content/public/browser/render_frame_host.h

Index: content/public/browser/render_frame_host.h
diff --git a/content/public/browser/render_frame_host.h b/content/public/browser/render_frame_host.h
index 4a45df26931abb1ed27289a49b4ede523d5b266c..a4559f8e597a0706efc385b2277d1cbd1791a1f0 100644
--- a/content/public/browser/render_frame_host.h
+++ b/content/public/browser/render_frame_host.h
@@ -188,7 +188,16 @@ class CONTENT_EXPORT RenderFrameHost : public IPC::Listener,
   // and still has a connection.  This is valid for all frames.
   virtual bool IsRenderFrameLive() = 0;
 
- private:
+#if defined(OS_ANDROID)
+  // Selects and zooms to the find result nearest to the point (x,y)
+  // defined in find-in-page coordinates.
+  virtual void ActivateNearestFindResult(int request_id, float x, float y) = 0;
+
+  // Asks the renderer to send the rects of the current find matches.

[nasko, 2016/01/20 21:43:32]

nit: s/renderer/renderer process/.

[paulmeyer, 2016/01/20 22:54:14]

Ah... I've seen these used interchangeably all over. I didn't realize that there
was any preference. I've likely used both in a number of places in upcoming CLs
as well, but I'll try to change them all to render process.

[nasko, 2016/01/20 23:38:26]

The rule of thumb we try to use is "renderer process" for genericly referring to
anything running in the renderer process. Otherwise the proper object name
should be used, RenderFrame/RenderFrameProxy/etc.

+  virtual void RequestFindMatchRects(int current_version) = 0;
+#endif
+
+private:
   // This interface should only be implemented inside content.
   friend class RenderFrameHostImpl;
   RenderFrameHost() {}