Remove kEnableResourceContentSettings and all the code that uses it since it's been behind a flag f…

Remove kEnableResourceContentSettings and all the code that uses it since it's been behind a flag for years and isn't used.

BUG=39252
R=bauerb@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=240115

[Bernhard Bauer, 2013-12-10 23:14:05]

https://codereview.chromium.org/106713004/diff/1/chrome/browser/content_setti...
File chrome/browser/content_settings/tab_specific_content_settings.h (left):

https://codereview.chromium.org/106713004/diff/1/chrome/browser/content_setti...
chrome/browser/content_settings/tab_specific_content_settings.h:298: const
std::string& resource_identifier);
I'm wondering if we should keep the resource identifier here, in case we want to
expose it via the contentSettings API at some point.

[Bernhard Bauer, 2013-12-10 23:16:41]

There's also more code that's hanging off the switch; see
ContentSettingTitleAndLinkModel::SetBlockedResources() and the UI classes for
the various platforms.

Okay, now that I think about it, if we don't pass the identifier for blocked
plugins anymore and that means that we can delete all that additional code in
the UI, I'm definitely in favor of doing that.

[jam, 2013-12-11 00:15:38]

On 2013/12/10 23:16:41, Bernhard Bauer wrote:
> There's also more code that's hanging off the switch; see
> ContentSettingTitleAndLinkModel::SetBlockedResources() and the UI classes for
> the various platforms.
> 
> Okay, now that I think about it, if we don't pass the identifier for blocked
> plugins anymore and that means that we can delete all that additional code in
> the UI, I'm definitely in favor of doing that.

ah, thanks I missed blocked_resources_ (I assume that's what you're referring
to?). I'll dig deeper.

https://codereview.chromium.org/106713004/diff/1/chrome/browser/content_setti...
File chrome/browser/content_settings/tab_specific_content_settings.h (left):

https://codereview.chromium.org/106713004/diff/1/chrome/browser/content_setti...
chrome/browser/content_settings/tab_specific_content_settings.h:298: const
std::string& resource_identifier);
On 2013/12/10 23:14:05, Bernhard Bauer wrote:
> I'm wondering if we should keep the resource identifier here, in case we want
to
> expose it via the contentSettings API at some point.

my philosophy is if we want to expose it, let's add it then

[jam, 2013-12-11 01:32:47]

ptal, hopefully I got everything but I haven't touched this code before, so
there's a good chance of missing deletions

[Bernhard Bauer, 2013-12-11 08:43:24]

Nice! LGTM w/ a nit below:

https://codereview.chromium.org/106713004/diff/70001/chrome/browser/ui/conten...
File chrome/browser/ui/content_settings/content_setting_bubble_model.cc (right):

https://codereview.chromium.org/106713004/diff/70001/chrome/browser/ui/conten...
chrome/browser/ui/content_settings/content_setting_bubble_model.cc:332:
ContentSetting most_restrictive_setting;
|most_restrictive_setting| etc. also date from when we used to[*] iterate over
all blocked plugins. Now that we don't anymore, it should simply be called
|setting|.

You can also move the declarations of |map| and |cookie_settings| to where they
are used, below.

[*] Ha, I'm already using past tense!

[jam, 2013-12-11 15:44:10]

https://codereview.chromium.org/106713004/diff/70001/chrome/browser/ui/conten...
File chrome/browser/ui/content_settings/content_setting_bubble_model.cc (right):

https://codereview.chromium.org/106713004/diff/70001/chrome/browser/ui/conten...
chrome/browser/ui/content_settings/content_setting_bubble_model.cc:332:
ContentSetting most_restrictive_setting;
On 2013/12/11 08:43:25, Bernhard Bauer wrote:
> |most_restrictive_setting| etc. also date from when we used to[*] iterate over
> all blocked plugins. Now that we don't anymore, it should simply be called
> |setting|.
> 
> You can also move the declarations of |map| and |cookie_settings| to where
they
> are used, below.
> 
> [*] Ha, I'm already using past tense!

Done.