[HBD] Update Plugins type in Website Settings Permissions UI

chrome/browser/ui/website_settings/website_settings_ui.cc

Index: chrome/browser/ui/website_settings/website_settings_ui.cc
diff --git a/chrome/browser/ui/website_settings/website_settings_ui.cc b/chrome/browser/ui/website_settings/website_settings_ui.cc
index 1632f9d8ad56c5e76ebc1e92e410a57e4f632432..207d194a5ff707d72ce4a08e71c9cd93b1960e28 100644
--- a/chrome/browser/ui/website_settings/website_settings_ui.cc
+++ b/chrome/browser/ui/website_settings/website_settings_ui.cc
@@ -6,6 +6,7 @@
 
 #include "base/macros.h"
 #include "chrome/browser/plugins/plugins_field_trial.h"
+#include "chrome/common/chrome_features.h"
 #include "chrome/grit/chromium_strings.h"
 #include "chrome/grit/generated_resources.h"
 #include "chrome/grit/theme_resources.h"
@@ -88,8 +89,8 @@ const PermissionsUIInfo kPermissionsUIInfo[] = {
     {CONTENT_SETTINGS_TYPE_POPUPS, IDS_WEBSITE_SETTINGS_TYPE_POPUPS,
      IDR_BLOCKED_POPUPS, IDR_ALLOWED_POPUPS},
 #if defined(ENABLE_PLUGINS)
-    {CONTENT_SETTINGS_TYPE_PLUGINS, IDS_WEBSITE_SETTINGS_TYPE_PLUGINS,
-     IDR_BLOCKED_POPUPS, IDR_ALLOWED_PLUGINS},
+    {CONTENT_SETTINGS_TYPE_PLUGINS, IDS_WEBSITE_SETTINGS_TYPE_FLASH,

[raymes, 2016/09/15 02:54:53]

As we discussed - we need to clarify/ensure this will only apply to flash and
not other custom plugins.

[raymes, 2016/09/15 03:21:34]

Now that I think about this more, I don't think this is really a problem for
Chrome. The only way a different plugin could get loaded is via command line
flags, which aren't really a supported use case. This may be a different story
for people with custom Chromium builds though, so we may want to consider
ensuring this only applies to flash.

[tommycli, 2016/09/15 16:40:45]

I filed this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=647284

+     IDR_BLOCKED_PLUGINS, IDR_ALLOWED_PLUGINS},
 #endif
     {CONTENT_SETTINGS_TYPE_GEOLOCATION, IDS_WEBSITE_SETTINGS_TYPE_LOCATION,
      IDR_BLOCKED_LOCATION, IDR_ALLOWED_LOCATION},
@@ -227,6 +228,14 @@ base::string16 WebsiteSettingsUI::PermissionActionToUIString(
 #if defined(ENABLE_PLUGINS)
   effective_setting =
       PluginsFieldTrial::EffectiveContentSetting(type, effective_setting);
+
+  // Display the UI string for ASK instead of DETECT for HTML5 by Default.
+  // TODO(tommycli): Once HTML5 by Default is shipped and the feature flag
+  // is removed, just migrate the actual content setting to ASK.
+  if (base::FeatureList::IsEnabled(features::kPreferHtmlOverPlugins) &&
+      effective_setting == CONTENT_SETTING_DETECT_IMPORTANT_CONTENT) {
+    effective_setting = CONTENT_SETTING_ASK;

[raymes, 2016/09/05 06:56:31]

I'm confused! In PluginsFieldTrial::EffectiveContentSetting there is a comment
which says "For Plugins, ASK is obsolete." and it returns
CONTENT_SETTING_DETECT_IMPORTANT_CONTENT if that feature is enabled, and then
here in that case we change it back to ask?

[tommycli, 2016/09/13 16:29:28]

It's unfortunate, but that's exactly what we want. Anyone with ASK in their
settings should get the DETECT behavior, since we don't support ASK anymore.
(Since Plugin Power Saver last year)

But for the HTML5 by Default feature, the behavior resembles ASK, and
eventually, once it's no longer a feature flag, we will migrate back to ASK. We
aren't actually migrating the settings yet because it's still shipping behind a
flag instead of permanently on.

It's unfortunate that we're flip flopping on the settings value, but we didn't
foresee the HTML5 by Default functionality when we worked on PPS.

And we can't just change EffectiveContentSetting, as that's used elsewhere in
the code also.

+  }
 #endif
 
   const int* button_text_ids = NULL;