[Contextual Search] Add Mojo-enabled API component.

chrome/browser/search/contextual_search_service.h

+// Copyright 2015 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 CHROME_BROWSER_SEARCH_CONTEXTUAL_SEARCH_SERVICE_H_
+#define CHROME_BROWSER_SEARCH_CONTEXTUAL_SEARCH_SERVICE_H_
+
+#include "base/memory/singleton.h"
+#include "content/public/browser/notification_observer.h"
+#include "content/public/browser/notification_registrar.h"
+
+// Provides a singleton service for Contextual Search.
+// Tracks render process host IDs that are associated with ContextualSearch.
+class ContextualSearchService : public content::NotificationObserver {
+ public:
+  static ContextualSearchService* GetInstance();
+
+  // Add, remove, and query RenderProcessHost IDs that are associated with
+  // Contextual Search processes.
+  void SetContextualSearchProcess(int process_id);
+  bool IsContextualSearchProcess(int process_id) const;
+
+ private:
+  // Use GetInstance instead of constructing.
+  ContextualSearchService();
+  ~ContextualSearchService() override;
+
+  // Singleton:
+  friend struct base::DefaultSingletonTraits<ContextualSearchService>;
+
+  // content::NotificationObserver:
+  void Observe(int type,
+               const content::NotificationSource& source,
+               const content::NotificationDetails& details) override;
+
+  void OnRendererProcessTerminated(int process_id);
+
+  // The process id associated with Contextual Search processes.
+  int process_id_;

[kmadhusu, 2015/10/08 22:05:02]

I am not sure if I understood the purpose of this class clearly. Do you want to
instantiate this class per profile or per renderer? This class is not doing any
service. It is just a notification observer.

When you used Singleton traits, I thought you are going to store a map/list of
process_ids. To my surprise, you are just storing one id. 

Is it the case that you will have at most one contextual search process at any
point?

[Donn Denman, 2015/10/09 20:46:43]

Right, this is a singleton class that just tracks which renderer(s) appear in a
Contextual Search Overlay, and therefor should enable our JS API.  Currently CS
only ever has one Overlay active, so this class only needs to track a single ID.
 But it was modeled after Instant, which tracks multiple IDs, and is a
full-fledged service, so that's a point of confusion.  

Maybe I should rename this class to ContextualSearchRendererTracker or something
like that?  I do think the current name does imply a global-singleton facility,
which seems useful.  Also it may need to expand slightly in order to be a
conduit to the Contextual Search Manager once messages from the wrapper are
being sent.

Pedro, do you have an opinion?

[pedro (no code reviews), 2015/10/20 01:24:41]

I am not familiar with the renderer code, so I don't know what is the best way
to integrate our code in it. If it turns out we only need a Observer, we could
call this class ContextualSearchRendererObserver.

On a side note, what happens in multi window device? In that case, there could
be two ContextualSearch ContentViews displayed at the same time. Would that be a
problem? I don't know if they share the browser process.

[Donn Denman, 2015/10/20 21:56:46]

Renamed ContextualSearchApiController, which seemed more descriptive of what it
does (rather than describing how it does that).
Although this appears to still be an open question, it should work fine even
with a shared browser process.  There's a very narrow window between when this
ID gets set during overlay creation and when it's checked during renderer
creation for that overlay, so a single value only needs to be valid in that
window.  I think it would be very hard for a user to manipulate both windows on
the device to do a Contextual Search simultaneously.

+
+  content::NotificationRegistrar registrar_;
+
+  DISALLOW_COPY_AND_ASSIGN(ContextualSearchService);
+};
+
+#endif  // CHROME_BROWSER_SEARCH_CONTEXTUAL_SEARCH_SERVICE_H_