Encapsulate CSS selector declarative content condition tracking

extensions/browser/api/declarative_content/content_rules_registry.h

Index: extensions/browser/api/declarative_content/content_rules_registry.h
diff --git a/extensions/browser/api/declarative_content/content_rules_registry.h b/extensions/browser/api/declarative_content/content_rules_registry.h
index f7f08bdb079a0ab36b3694c7ede75938861a130c..25c3ee6e42e3784959a0d079c5d22340d26029ba 100644
--- a/extensions/browser/api/declarative_content/content_rules_registry.h
+++ b/extensions/browser/api/declarative_content/content_rules_registry.h
@@ -36,12 +36,6 @@ class ContentRulesRegistry : public RulesRegistry {
                       cache_delegate,
                       rules_registry_id) {}
 
-  // Applies all content rules given an update (CSS match change or
-  // page navigation, for now) from the renderer.
-  virtual void Apply(
-      content::WebContents* contents,
-      const std::vector<std::string>& matching_css_selectors) = 0;
-
   // Applies all content rules given that a tab was just navigated.
   virtual void DidNavigateMainFrame(

[not at google - send to devlin, 2015/06/01 22:51:12]

Writing comment here, though I first noticed it in implementations:

A method like "DidNavigateMainFrame" is odd as an interface method, because it's
not an action, rather a notification - and notifications should be handled
within the implementation of classes. Looking at where it's called, it seems to
just forward this event through to something else that could be listening to
those events.

Would it be easier to do this in a follow-up, though?

[Mike Wittman, 2015/06/05 01:17:45]

It would. My intention is to move the notification handling from TabHelper to
ChromeContentRulesRegistry with my next CL, which will encapsulate the URL
matcher. I'll need to update the logic in this function then as well.

See also my comment on this function in DeclarativeContentCssConditionTracker.

       content::WebContents* tab,