Put some plug-ins behind an infobar, where they have:...

chrome/renderer/render_view.cc

 // Copyright (c) 2011 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.
 
 #include "chrome/renderer/render_view.h"
 
 #include <algorithm>
 #include <cmath>
 #include <string>
 #include <vector>
@@ skipping 2687 matching lines @@
 
   if (!found)
     return NULL;
   DCHECK(plugin_setting != CONTENT_SETTING_DEFAULT);
 
   const webkit::npapi::PluginGroup* group =
       webkit::npapi::PluginList::Singleton()->GetPluginGroup(info);
   DCHECK(group != NULL);
 
   if (group->IsVulnerable() &&
       !cmd->HasSwitch(switches::kAllowOutdatedPlugins)) {

[Bernhard Bauer, 2011/01/24 12:56:33]

What is the interaction with blocking outdated plugins? If someone uses an old
version of Quicktime, will they get an infobar telling them to upgrade, and
after they have upgraded, this one? Right now, I'm trying to use the outdated
plugin infobar to incentivize people to upgrade their plugins ("if you want to
get rid of this infobar, upgrade your plugin"), and if you're always going to
get the infobar, that incentive goes away.

     Send(new ViewHostMsg_BlockedOutdatedPlugin(routing_id_,
                                                group->GetGroupName(),
                                                GURL(group->GetUpdateURL())));
     return CreatePluginPlaceholder(frame,
                                    params,
                                    *group,
                                    IDR_BLOCKED_PLUGIN_HTML,
                                    IDS_PLUGIN_OUTDATED,
                                    false);
   }
 
   if (!info.enabled)
     return NULL;
 
   ContentSetting host_setting =
       current_content_settings_.settings[CONTENT_SETTINGS_TYPE_PLUGINS];
+
+  if (group->RequiresAuthorization() &&
+      !cmd->HasSwitch(switches::kAlwaysAuthorizePlugins) &&
+      plugin_setting == CONTENT_SETTING_ALLOW &&
+      host_setting == CONTENT_SETTING_DEFAULT) {

[Bernhard Bauer, 2011/01/24 12:56:33]

Combined with the changes in HostContentSettingsMap, what are the precedences
now? IIUC, in order for someone to get the infobar, they need to have a default
plugin setting of "Allow" and no exceptions (of any sort) for the current
website, correct?

+    // TODO(cevans) - may need some form of "always allow this web site",
+    // either via an explicit button or integration with the blocked-plugin
+    // bubble.
+    Send(new ViewHostMsg_BlockedOutdatedPlugin(routing_id_,
+                                               group->GetGroupName(),
+                                               GURL()));
+    return CreatePluginPlaceholder(frame,
+                                   params,
+                                   *group,
+                                   IDR_BLOCKED_PLUGIN_HTML,
+                                   IDS_PLUGIN_NOT_AUTHORIZED,
+                                   false);
+  }
+
   if (info.path.value() == webkit::npapi::kDefaultPluginLibraryName ||
       plugin_setting == CONTENT_SETTING_ALLOW ||
       host_setting == CONTENT_SETTING_ALLOW) {
     // Delay loading plugins if prerendering.
     WebDataSource* ds = frame->dataSource();
     NavigationState* navigation_state = NavigationState::FromDataSource(ds);
     if (navigation_state->is_prerendering()) {
       return CreatePluginPlaceholder(frame,
                                      params,
                                      *group,
@@ skipping 3012 matching lines @@
   if (cmd == kJavaScriptStressTestSetStressRunType) {
     v8::Testing::SetStressRunType(static_cast<v8::Testing::StressType>(param));
   } else if (cmd == kJavaScriptStressTestPrepareStressRun) {
     v8::Testing::PrepareStressRun(param);
   }
 }
 
 void RenderView::OnContextMenuClosed() {
   context_menu_node_.reset();
 }