Check whether the Pepper CDM is available before adding the key system.

content/public/browser/plugin_service.h

Index: content/public/browser/plugin_service.h
diff --git a/content/public/browser/plugin_service.h b/content/public/browser/plugin_service.h
index 8c28948d21af534755483edb377d70d46ebea467..556d284e027448b99b57030d553f520ec5f881c6 100644
--- a/content/public/browser/plugin_service.h
+++ b/content/public/browser/plugin_service.h
@@ -102,6 +102,12 @@ class PluginService {
   virtual PepperPluginInfo* GetRegisteredPpapiPluginInfo(
       const base::FilePath& plugin_path) = 0;
 
+  // Returns whether any Pepper plugin supporting |mime_type| is registered.
+  // Does not determine whether the plugin can actually be instantiated
+  // (e.g. whether it is allowed or has all its dependencies).
+  virtual bool IsPepperPluginRegisteredForMimeType(

[jam, 2013/09/17 00:27:57]

seems that you can avoid changing content, since chrome is the one that told
content about which pepper plugins are available. so why do you need to go back
into content to ask it information which you gave it? if it's because that
chrome doesn't keep track of this (not sure?) then you can get this data from
the GetPlugins callback?

[ddorwin, 2013/09/17 01:41:18]

Yes, it's because chrome doesn't keep track (and plugins are registered from
multiple locations that all uses content's PluginService as the central point.
For example, component-installed plugins:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/com...

tl;dr: I found that PluginServiceImpl::pepper_plugins_ doesn't provide what I
needed on all platforms and I need to use PluginService::GetInternalPlugins(),
so I _don't_ need to change content, but I do need to call back into content.
However, see the next paragraph.

Problem: Using PluginService::GetInternalPlugins() means we can no longer
register our test CDM (External Clear Key) on the command line because it is not
internal and only appears in PluginServiceImpl::pepper_plugins_. I guess we can
solve that by making it an internal plugin that is normally not present because
it can't be found. This might add a slight delay to Chrome startup (equivalent
to that of any other internal Pepper plugin). Other options: a) Add a command
line flag for the test CDM (just optimizes out the File::Exists check in the
normal case) b) Make PluginService::RegisterInternalPlugins() add
PLUGIN_TYPE_PEPPER_* plugins to pepper_plugins_ and revert back to Patch Set 8,
which does require content changes.

Details:
PluginList::plugins_list_ (and now I've found
PluginServiceImpl::pepper_plugins_) don't include (all) the plugins I care
about. It appears only PluginList::internal_plugins_ does. I've switched the
implementation to use this.

GetPlugins() "Asynchronously loads plugins if necessary and then calls back..."
In Patch Set 1, I was trying to use GetPluginInfoArray(), but, like I believe
GetPlugins() does, it uses PluginList, which only returns information if the
plugin has been loaded (or is NPAPI/external?) and is thus in plugins_list_. It
doesn't check internal_plugins_. Since we want to query availability before
loading, this wouldn't work. Specifically, manual tests failed sometime (though
I didn't know exactly why at the time) and the browser tests were failing.

Unfortunately, there are several lists of plugins that aren't all in agreement.
PluginList::plugins_list_ appears to include only loaded plugins (and maybe
NPAPI?). PluginServiceImpl::pepper_plugins_ includes packaged Pepper Plugins but
not component-installed plugins. PluginList::internal_plugins_ includes all
internal plugins, which I believe includes all Pepper Plugins, including
component-installed ones. There is also PepperPluginRegistry, which doesn't do
what one would expect (crbug.com/277039).

[Bernhard Bauer, 2013/09/17 14:52:57]

For locations in chrome/ that register plug-ins on the PluginService, we *could*
of course also store the information somewhere in chrome/. But plug-ins added on
the command line are registered directly in PluginServiceImpl.
Why is that? If we register an internal plugin, we don't need to look at the
file on disk.
What exactly do you mean by "loaded plugins"? GetPluginInfoArray() will return
all plugins that PluginList knows about. i.e. for which it has a WebPluginInfo.
The WebPluginInfo usually comes from the .so/.dll/.plugin on disk, but can also
be provided manually for internal plugins. The registered Pepper plugins (i.e.
the ones added by ChromeContentBrowserClient or coming from the command line)
are also registered as internal plugins AFAIK (see
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/pl...).

[ddorwin, 2013/09/17 17:19:53]

We don't need to load it, but we make sure PathExists:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/chro...
Those plugins are registered as internal plugins, which means they are added to
internal_plugins_. GetPluginInfoArray() only reads plugins_list_.

plugins_list_ appears to be populated by LoadPlugins(). It calls
GetPluginPathsToLoad(), which uses extra_plugin_paths_, to which the internal
plugins were added. So GetPluginInfoArray() will return the internal Pepper
plugins, but only after LoadPlugins() has been called (again?).

When is LoadPlugins() called? It doesn't appear to be called after internal
plugin registration until a plugin is needed, at least on Linux.

+      const std::string& mime_type) = 0;
+
   virtual void SetFilter(PluginServiceFilter* filter) = 0;
   virtual PluginServiceFilter* GetFilter() = 0;