Use a placeholder instead of the default plugin for missing plug-ins on Mac and Linux.

content/browser/plugin_service.h

Index: content/browser/plugin_service.h
diff --git a/content/browser/plugin_service.h b/content/browser/plugin_service.h
index f662b33f0a78c825b00518e76e787a1eb558ae16..52a0fbbc5f476f29daf5c02a7f8c6263f73073dc 100644
--- a/content/browser/plugin_service.h
+++ b/content/browser/plugin_service.h
@@ -63,13 +63,6 @@ class CONTENT_EXPORT PluginService
     : public base::WaitableEventWatcher::Delegate,
       public NotificationObserver {
  public:
-  struct OverriddenPlugin {
-    int render_process_id;
-    int render_view_id;
-    GURL url;  // If empty, the override applies to all urls in render_view.
-    webkit::WebPluginInfo plugin;
-  };
-
   typedef base::Callback<void(const std::vector<webkit::WebPluginInfo>&)>
       GetPluginsCallback;
   typedef base::Callback<void(const std::vector<webkit::npapi::PluginGroup>&)>
@@ -133,6 +126,20 @@ class CONTENT_EXPORT PluginService
                      webkit::WebPluginInfo* info,
                      std::string* actual_mime_type);
 
+  // Returns a list of all plug-ins that match the given URL and MIME type.
+  void GetMatchingPlugins(

[jam, 2011/09/27 16:51:34]

nit: it seems that this is equivalent to GetPluginInfo but returns an array. Can
you call it GetPluginsInfo to match the existing terminology? the fewer plugin
related names we have, the easier it is for people to guess what a function/ipc
does

[Bernhard Bauer, 2011/09/27 21:21:39]

That's why I tried to give it a more descriptive name ;) Plugin is conceptually
equal to PluginInfo, so GetPluginInfos wouldn't tell anything about the set of
PluginInfos it returns. If we'd rename GetPluginInfo to GetMatchingPlugin, we'd
have GetPlugins (all plug-ins), GetMatchingPlugins (all matching plug-ins), and
GetMatchingPlugin (first matching and allowed plug-in).

[jam, 2011/09/29 01:03:32]

You lost me here :) I'm still not clear why GetPluginsInfo wouldn't be good,
i.e. wouldn't anyone who wants one or multiple plugin always want the "matching"
ones? How is this match different than GetPluginInfo?
 

[Bernhard Bauer, 2011/09/29 13:20:47]

It's not, that's why I'd prefer to rename GetPluginInfo instead ;-) The only
difference in name between GetPlugins and GetPluginInfos is the "Infos" (which
doesn't convey any information by itself), but there is a big difference in the
set of plug-ins that is returned. It's not obvious that one returns *all*
plug-ins, whereas the other returns only matching plug-ins.

[jam, 2011/09/29 16:31:10]

Ok I think I understand your point now, which is that GetPluginsInfo is too
similar to the existing GetPlugins (I was comparing it to GetPluginInfo)

+      int render_process_id,
+      int render_view_id,
+      const content::ResourceContext& context,
+      const GURL& url,
+      const GURL& page_url,
+      const std::string& mime_type,
+      bool allow_wildcard,
+      bool* use_stale,

[Robert Sesek, 2011/09/29 01:09:48]

This isn't going to work with the direction we're going. Plugin loading will
only happen on the FILE thread on Windows; Linux and Mac are going to be OOP
(Mac already is). Callers need to either accept stale data, or should call
GetPlugins() first to ensure it is up-to-date.

[jam, 2011/09/29 01:13:49]

right, I think Bernhard's change is from a revision before your change. Once he
syncs he would get a CHECK failure :) If this is just a separate IPC that chrome
sends, then the dispatcher will call PluginService::GetPlugins asynchronously
and then filter when the results come back.

[Bernhard Bauer, 2011/09/29 13:20:47]

No, I did not get a CHECK :) Note that this is essentially the same as the
already existing GetPluginInfo method, it just returns all matching plug-ins
instead of the first enabled one. That's also why the signature is so similar.
If the signature of GetPluginInfo should change before this CL is landed, I'll
just update this method's signature accordingly.

[jam, 2011/09/29 16:31:10]

hmm, probably because it was cached then.

+      std::vector<webkit::WebPluginInfo>* plugins,
+      std::vector<std::string>* mime_types,

[Robert Sesek, 2011/09/29 01:09:48]

I'm adding a function that is very similar to this in a WIP.
http://codereview.chromium.org/8071013

It's not quite ready for review, though.

+      std::vector<bool>* allowed);
+
   // Marks the plugin list as dirty and will cause the plugins to be reloaded
   // on the next access through GetPlugins() or GetPluginGroups().
   void RefreshPluginList();