Prepare declarativeContent API for new script injection feature. Added Javascript types and functio…

chrome/browser/extensions/api/declarative/rules_registry_service.h

 // Copyright (c) 2012 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_EXTENSIONS_API_DECLARATIVE_RULES_REGISTRY_SERVICE_H__
 #define CHROME_BROWSER_EXTENSIONS_API_DECLARATIVE_RULES_REGISTRY_SERVICE_H__
 
 #include <map>
 #include <string>
 #include <vector>
 
 #include "base/callback_forward.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_vector.h"
 #include "base/scoped_observer.h"
 #include "chrome/browser/extensions/api/declarative/rules_registry.h"
+#include "chrome/browser/extensions/api/declarative_content/content_rules_registry.h"
 #include "chrome/browser/profiles/profile.h"
 #include "content/public/browser/notification_observer.h"
 #include "content/public/browser/notification_registrar.h"
 #include "extensions/browser/browser_context_keyed_api_factory.h"
 #include "extensions/browser/extension_registry_observer.h"
 
 class Profile;
 
 namespace content {
 class BrowserContext;
 class NotificationSource;
 }
 
 namespace extensions {
-class ContentRulesRegistry;
 class ExtensionRegistry;
 class RulesRegistry;
 class RulesRegistryStorageDelegate;
 }
 
 namespace extensions {
 
 // This class owns all RulesRegistries implementations of an ExtensionService.
 // This class lives on the UI thread.
 class RulesRegistryService : public BrowserContextKeyedAPI,
@@ skipping 35 matching lines @@
   // Registers a RulesRegistry and wraps it in an InitializingRulesRegistry.
   void RegisterRulesRegistry(scoped_refptr<RulesRegistry> rule_registry);
 
   // Returns the RulesRegistry for |event_name| and |webview_key| or NULL if no
   // such registry has been registered. Default rules registries (such as the
   // WebRequest rules registry) will be created on first access.
   scoped_refptr<RulesRegistry> GetRulesRegistry(
       const WebViewKey& webview_key,
       const std::string& event_name);
 
-  // Accessors for each type of rules registry.
-  ContentRulesRegistry* content_rules_registry() const {
-    CHECK(content_rules_registry_);
-    return content_rules_registry_;
+  // Accessors for content rules registries.
+  std::map<std::string, ContentRulesRegistry*>& content_rules_registry_map() {
+    return content_rules_registry_map_;
   }
+  ContentRulesRegistry* GetContentRulesRegistry(
+      const std::string& event_name);
 
   // Removes all rules registries of a given webview embedder process ID.
   void RemoveWebViewRulesRegistries(int process_id);
 
   // For testing.
   void SimulateExtensionUninstalled(const std::string& extension_id);
 
  private:
   friend class BrowserContextKeyedAPIFactory<RulesRegistryService>;
 
@@ skipping 30 matching lines @@
     return "RulesRegistryService";
   }
   static const bool kServiceHasOwnInstanceInIncognito = true;
   static const bool kServiceIsNULLWhileTesting = true;
 
   RulesRegistryMap rule_registries_;
 
   // We own the parts of the registries which need to run on the UI thread.
   ScopedVector<RulesCacheDelegate> cache_delegates_;
 
-  // Weak pointer into rule_registries_ to make it easier to handle content rule
-  // conditions.
-  ContentRulesRegistry* content_rules_registry_;
+  // Collection of content rule registries to make it easier to handle content

[Jeffrey Yasskin, 2014/07/15 17:12:59]

You've removed the information about what structure owns these pointers. That
was important, so please put it back.

'course, this change might not be necessary anymore since there's only 1 event
at the moment. Even when there are multiple events in the API, we might still
want to track them with a single registry, since they affect when the actions
fire, rather than what information is stored.

[Mark Dittmer, 2014/07/15 18:32:42]

Fixed comment to refer to weak pointers. When/if we add multiple events, we
would need to rethink binding event names if we want to keep a single registry.
Right now, one (and only one) event name is tied to each registry. This seemed
like a simpler pattern of composition than refactoring registry code to track
and properly dispatch on multiple event names.

For this CL, our options are (1) revert this part of the change since there's
only one event so far, (2) keep the change to avoid refactoring event name
binding, or (3) refactor event name binding as a part of this CL. What's your
preference?

+  // rule conditions.
+  std::map<std::string, ContentRulesRegistry*> content_rules_registry_map_;
 
   content::NotificationRegistrar registrar_;
 
   // Listen to extension load, unloaded notification.
   ScopedObserver<ExtensionRegistry, ExtensionRegistryObserver>
       extension_registry_observer_;
 
   Profile* profile_;
 
   DISALLOW_COPY_AND_ASSIGN(RulesRegistryService);
 };
 
 }  // namespace extensions
 
 #endif  // CHROME_BROWSER_EXTENSIONS_API_DECLARATIVE_RULES_REGISTRY_SERVICE_H__