Implement a shell of FindRequestManager, and hook it up to WebContentsImpl.

content/browser/find_request_manager.h

+// Copyright 2016 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.
+
+// FindRequestManager manages all of the find-in-page requests/replies
+// initiated/received through a WebContents.
+
+#ifndef CONTENT_BROWSER_FIND_REQUEST_MANAGER_H_
+#define CONTENT_BROWSER_FIND_REQUEST_MANAGER_H_
+
+#include <set>
+#include <vector>
+
+#include "content/public/common/stop_find_action.h"
+#include "third_party/WebKit/public/web/WebFindOptions.h"
+#include "ui/gfx/geometry/rect.h"
+#include "ui/gfx/geometry/rect_f.h"
+
+namespace content {
+
+class RenderFrameHost;
+class WebContentsImpl;
+
+class FindRequestManager {

[ncarter (slow), 2016/04/06 19:08:03]

Could you add a class comment here?

You can probably just paraphrase the first couple paragraphs of your excellent
design doc.

[paulmeyer, 2016/04/07 17:36:14]

Done.

+ public:
+  explicit FindRequestManager(WebContentsImpl* web_contents);
+  ~FindRequestManager();
+
+  // Initiates a find operation for |search_text| with the options specified in
+  // |options|. |request_id| uniquely identifies the find request.
+  void Find(int request_id,
+            const base::string16& search_text,
+            const blink::WebFindOptions& options);
+
+  // Stops the active find session and clears the general highlighting of the
+  // matches. |action| determines whether the last active match (if any) will be
+  // activated, cleared, or remain highlighted.
+  void StopFinding(StopFindAction action);
+
+  // Called when a reply is received from a frame with the results from a
+  // find request.
+  void FindReply(RenderFrameHost* rfh,

[ncarter (slow), 2016/04/06 19:08:03]

What would you think about naming this method (and FindMatchRectsReply) to have
an "On" prefix? That makes it a little clearer that these events are triggered
by an IPC.

[paulmeyer, 2016/04/07 17:36:15]

That sounds reasonable. Done.

+                 int request_id,
+                 int number_of_matches,
+                 const gfx::Rect& selection_rect,
+                 int active_match_ordinal,
+                 bool final_update);
+
+#if defined(OS_ANDROID)
+  // Selects and zooms to the find result nearest to the point (x,y) defined in
+  // find-in-page coordinates.
+  void ActivateNearestFindResult(float x, float y);
+
+  // Requests the rects of the current find matches from the renderer process.
+  void RequestFindMatchRects(int current_version);
+
+  // Called when a reply is received in response to a request for find match
+  // rects.
+  void FindMatchRectsReply(RenderFrameHost* rfh,
+                           int version,
+                           const std::vector<gfx::RectF>& rects,
+                           const gfx::RectF& active_rect);
+#endif
+
+private:
+  // Reset all of the per-session state for a new find-in-page session.
+  void Reset(int new_session_id, const base::string16& new_search_text);
+
+  // Send a find IPC to the RenderFrame associated with |rfh| to begin a find
+  // operation with the search text |current_search_text_| and the find options
+  // in |current_find_options_|.
+  void SendFindIPC(int request_id, RenderFrameHost* rfh);
+
+  // Send a stop finding IPC to the RenderFrame associated with
+  // |render_frame_host|.
+  void SendStopFindingIPC(StopFindAction action,
+                          RenderFrameHost* rfh) const;
+
+  // Send the find results (as they currently are) to the WebContents.
+  void SendFindReply(int request_id, bool final_update) const;
+
+#if defined(OS_ANDROID)
+  // Request the latest find match rects from a frame.
+  void SendFindMatchRectsIPC(RenderFrameHost* rfh);
+
+  // The latest find match rects version known by the requester.
+  int fmr_request_version_;

[ncarter (slow), 2016/04/06 19:08:03]

fmr -> former (
https://google.github.io/styleguide/cppguide.html#General_Naming_Rules )

[paulmeyer, 2016/04/07 17:36:15]

Actually, "fmr" here means "Find Match Rects". In upcoming CLs, I have even more
variables prefixed with "fmr", and some others prefixed with "nfr" (meaning
"Nearest Find Results", which will be explained in comments). I just didn't want
all of these variables to be too long, so I shortened them like "rfh" often is.

[ncarter (slow), 2016/04/07 18:19:14]

We almost always avoid abbreviations in the names of data members. My
misintepretation of 'fmr' as 'former' here is a good real-life example of why we
have that rule, which reads as follows:

"""Names should be descriptive; eschew abbreviation. Give as descriptive a name
as possible, within reason. Do not worry about saving horizontal space as it is
far more important to make your code immediately understandable by a new reader.
Do not use abbreviations that are ambiguous or unfamiliar to readers outside
your project, and do not abbreviate by deleting letters within a word."""

Because this class is Find-focused, we can probably omit 'Find' from a bunch of
member names. So fmr_request_version_ could become:

match_rects_request_version_

Which doesn't look too long to me.

You can also use sub-structs/classes for grouping, though the boilerplate
required (e.g. initialization can get harder to grok) isn't always worth it:

struct FindMatchRectsState {
  request_version;
};
FindMatchRectsState match_rects_;

An upside to such grouping is that you can define e.g. a Reset() operation in
terms of "match_rects_ = FindMatchRectsState();"

[paulmeyer, 2016/04/11 19:35:49]

I like the idea of grouping. I've decided to also make a struct for FindRequest
to encompass a single request's ID, search text, and options.

+#endif
+
+  // The WebContents that owns this FindRequestManager.
+  WebContentsImpl* const contents_;
+
+  // The find request ID that uniquely identifies this find-in-page session (The
+  // ID of the initial request of this session). Request IDs are included in all
+  // find-related IPCs, which allows IPCs containing results from previous
+  // sessions to be easily identified and ignored.
+  int current_session_id_;

[ncarter (slow), 2016/04/06 19:08:03]

We could consider making find-in-page code use typed IDs, a la SavePackageId.
Seems like a good fit here, to help distinguish request_version vs session_id vs
request_id.

(some background: Currently IdType32 lives in gpu, but it's okay to use in
content. If it picks up sufficiently many users, we hope to promote it to base.
lukasza is the expert on this and would be happy to answer questions)

If you want to do that, a follow-on CL would be totally fine.

[paulmeyer, 2016/04/07 17:36:15]

I would prefer to keep these as ints. Session IDs and request IDs are actually
the same type of ID, and request versions are different but are only used in one
android-specific case. I have updated some comments to hopefully make these IDs
more clear.

[ncarter (slow), 2016/04/07 18:19:14]

OK.

+
+  // The text that is being searched for in the current find-in-page session.
+  base::string16 current_search_text_;
+
+  // The current set of find options in effect.
+  blink::WebFindOptions current_find_options_;
+
+  // The total number of matches found in the current find-in-page session.
+  int number_of_matches_;
+
+  // The overall active match ordinal for the current find-in-page session.
+  int active_match_ordinal_;
+
+  // The rectangle around the active match, in screen coordinates.
+  gfx::Rect selection_rect_;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_FIND_REQUEST_MANAGER_H_