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

content/browser/find_request_manager.cc

+// 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.
+
+#include "content/browser/find_request_manager.h"
+
+#include "content/browser/frame_host/render_frame_host_impl.h"
+#include "content/browser/web_contents/web_contents_impl.h"
+#include "content/common/frame_messages.h"
+#include "content/common/input_messages.h"
+
+namespace content {
+
+namespace {
+
+// An invalid ID. This value is invalid for any render process ID, render frame
+// ID, or find request ID.
+const int kInvalidId = -1;
+
+}  // namespace
+
+FindRequestManager::FindRequestManager(WebContentsImpl* web_contents)
+    : contents_(web_contents),
+      current_session_id_(kInvalidId),
+      number_of_matches_(0),
+      active_match_ordinal_(0) {}
+
+FindRequestManager::~FindRequestManager() {}
+
+void FindRequestManager::Find(int request_id,

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

if request_id is comparable to current_session_id, should one of them be renamed
to match the other?

The multiplicity of id flavors is a little hard to follow.

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

Yeah, they can be a bit confusing. Ironically, |current_session_id_| was called
|current_request_id_| until very recently when I changed it to "session" it in
order to make it more clear. :)

Basically, the session ID is a find request ID, but it is specifically the
request ID of the initial find request in a single find session (a group of
consecutive find requests for the same search string, consisting of an initial
find request to find all of the matches, followed by any number of "find next"
requests that just advance the active match). Because this variable actually
tracks the initial find request ID, which does not change throughout a find
session, it really identifies the whole session, not just one find request, so I
changed the name to reflect that.

This rename was also necessary because I recently had the need to additionally
keep track of the find request ID of the latest individual request sent, so I
called THAT variable |current_request_id_| instead. I think I'll add that into
this CL and hopefully the set of comments will make the difference clear.

Some context: previously, for some find helpers (like FindTabHelper), all find
requests in the same session were given the same request IDs (because there was
no need to differentiate their replies), while for some others (like
WebViewFindHelper), every request was given a unique ID because their replies
needed to be matched up with specific callbacks. This led to request IDs
sometimes identifying specific find requests, and sometimes just identifying
which find session the requests belong to. In both cases, they were just called
"request IDs", which was somewhat confusing. As part of the multi-process
find-in-page implementation, I was forced to make it so that all requests always
get unique IDs, because FindRequestManager will (in an upcoming CL) need to
differentiate all requests from each other. That being said, it also needs to
keep track of the ID for the first request in the session, so that it can easily
disregard replies with lower IDs that must have come from an older session
(which don't matter anymore). I introduced the term "session ID" so that it is
more clear what an ID is actually identifying.

In summary, the session ID is similar to a request ID, but only updates once per
find session instead of for every request. They always match up so that when a
new find session begins with an initial request, the request ID is updated and
then the session ID is updated to match the initial request ID. It is then easy
to tell when replies come in with request_id < current_session_id_ that they
must be from a previous session and should be ignored.

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

Oh, everything makes a lot more sense knowing this. The new comment on
current_session_id_ definitely helps clarify.

+                              const base::string16& search_text,
+                              const blink::WebFindOptions& options) {
+  DCHECK(request_id > current_session_id_);

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

DCHECK_GT.

Also could you add a comment (or << "log statement") explaining why this is an
invariant?

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

Done.

+  current_find_options_ = options;
+
+  if (!options.findNext)
+    Reset(request_id, search_text);
+
+  SendFindIPC(request_id, contents_->GetMainFrame());
+}
+
+void FindRequestManager::StopFinding(StopFindAction action) {
+  SendStopFindingIPC(action, contents_->GetMainFrame());
+  current_session_id_ = kInvalidId;
+}
+
+void FindRequestManager::FindReply(RenderFrameHost* rfh,
+                                   int request_id,
+                                   int number_of_matches,
+                                   const gfx::Rect& selection_rect,
+                                   int active_match_ordinal,
+                                   bool final_update) {
+  // Ignore stale replies from abandoned find sessions.
+  if (current_session_id_ == kInvalidId || request_id < current_session_id_)
+    return;
+
+  // Update the stored results.
+  number_of_matches_ = number_of_matches;
+  selection_rect_ = selection_rect;
+  active_match_ordinal_ = active_match_ordinal;
+
+  SendFindReply(request_id, final_update);
+}
+
+#if defined(OS_ANDROID)
+void FindRequestManager::ActivateNearestFindResult(float x,
+                                                   float y) {
+  if (current_session_id_ == kInvalidId)
+    return;
+
+  auto rfh = contents_->GetMainFrame();
+  rfh->Send(new InputMsg_ActivateNearestFindResult(
+      rfh->GetRoutingID(), current_session_id_, x, y));
+}
+
+void FindRequestManager::RequestFindMatchRects(int current_version) {
+  fmr_request_version_ = current_version;
+  SendFindMatchRectsIPC(contents_->GetMainFrame());
+}
+
+void FindRequestManager::FindMatchRectsReply(
+    RenderFrameHost* rfh,
+    int version,
+    const std::vector<gfx::RectF>& rects,
+    const gfx::RectF& active_rect) {
+  contents_->FindMatchRectsReply(version, rects, active_rect);
+}
+#endif
+
+void FindRequestManager::Reset(int new_session_id,
+                               const base::string16& new_search_text) {
+  current_session_id_ = new_session_id;
+  current_search_text_ = new_search_text;
+  number_of_matches_ = 0;
+  active_match_ordinal_ = 0;
+  selection_rect_ = gfx::Rect();
+}
+
+void FindRequestManager::SendFindIPC(int request_id, RenderFrameHost* rfh) {
+  rfh->Send(new FrameMsg_Find(rfh->GetRoutingID(), request_id,
+                              current_search_text_, current_find_options_));
+}
+
+void FindRequestManager::SendStopFindingIPC(StopFindAction action,
+                                            RenderFrameHost* rfh) const {
+  rfh->Send(new FrameMsg_StopFinding(rfh->GetRoutingID(), action));
+}
+
+void FindRequestManager::SendFindReply(int request_id,

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

I propose we rename both FindRequestManager::SendFindReply and
WebContentsImpl::FindReply to have the same name, like "NotifyFindReply".

My reasoning: this method is called Send, but it doesn't seem to send an IPC
message, so the name is inconsistent with how Send is used elsewhere in the
class. "Notify" is probably a better verb for this -- there is precedent for
that in WebContentsImpl, e.g. WebContentsImpl::NotifyNavigationStateChanged.

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

You're right, "Send" doesn't fit. "Notify" seems more reasonable to me too.
Done.

+                                       bool final_update) const {
+  if (request_id == kInvalidId) {
+    NOTREACHED();
+    return;
+  }
+
+  contents_->FindReply(request_id, number_of_matches_, selection_rect_,
+                       active_match_ordinal_, final_update);
+}
+
+#if defined(OS_ANDROID)
+void FindRequestManager::SendFindMatchRectsIPC(RenderFrameHost* rfh) {
+  rfh->Send(new FrameMsg_FindMatchRects(rfh->GetRoutingID(),
+                                        fmr_request_version_));
+}
+#endif
+
+}  // namespace content