[subresource_filter] Implement the "Smart" UI on Android

components/content_settings/core/common/content_settings_types.h

Index: components/content_settings/core/common/content_settings_types.h
diff --git a/components/content_settings/core/common/content_settings_types.h b/components/content_settings/core/common/content_settings_types.h
index d7584141be5b3c85efbc0a95535a443f41fa0b0b..3c31cde2ea03c9f91a05a045a72907f4a518eaa1 100644
--- a/components/content_settings/core/common/content_settings_types.h
+++ b/components/content_settings/core/common/content_settings_types.h
@@ -50,6 +50,11 @@ enum ContentSettingsType {
   CONTENT_SETTINGS_TYPE_PERMISSION_AUTOBLOCKER_DATA,
   CONTENT_SETTINGS_TYPE_SUBRESOURCE_FILTER,
 
+  // Website setting which stores metadata for the subresource filter to aid in
+  // decisions for whether or not to show the UI. Currently only used on
+  // Android.

[Charlie Harrison, 2017/04/26 16:33:23]

raymes: We could re-use this website setting to implement the blacklist cache
we've talked about.

[msramek, 2017/05/08 16:40:26]

This wasn't addressed to me, I just want to +1 reusing the same setting.

It's a dictionary, so you can just use different keys to access different
metadata; this shouldn't add any complexity. What might add a bit of complexity
is if the deletion criteria differ.

[Charlie Harrison, 2017/05/08 20:57:21]

I don't even think we need to add another key, we can just query for existence
of this data. I have a WIP CL here implementing that:
https://codereview.chromium.org/2859783002/

+  CONTENT_SETTINGS_TYPE_SUBRESOURCE_FILTER_DATA,
+
   // This is special-cased in the permissions layer to always allow, and as
   // such doesn't have associated prefs data.
   CONTENT_SETTINGS_TYPE_MIDI,