Don't block shared_module extensions by the policy blacklist.

chrome/browser/extensions/crx_installer.cc

Index: chrome/browser/extensions/crx_installer.cc
diff --git a/chrome/browser/extensions/crx_installer.cc b/chrome/browser/extensions/crx_installer.cc
index 9402445f083154d4af5b31ce3454ddd0f8558e32..731c8ef9a36f9041657b7617280a7997e66cf287 100644
--- a/chrome/browser/extensions/crx_installer.cc
+++ b/chrome/browser/extensions/crx_installer.cc
@@ -486,14 +486,8 @@ void CrxInstaller::CheckInstall() {
       Version version_required(i->minimum_version);
       const Extension* imported_module =
           service->GetExtensionById(i->extension_id, true);
-      if (!imported_module) {
-        ReportFailureFromUIThread(CrxInstallerError(l10n_util::GetStringFUTF16(
-            IDS_EXTENSION_INSTALL_DEPENDENCY_NOT_FOUND,
-            base::ASCIIToUTF16(i->extension_id),
-            base::ASCIIToUTF16(i->minimum_version))));
-        return;
-      } else if (imported_module &&
-                 !SharedModuleInfo::IsSharedModule(imported_module)) {
+      if (imported_module &&

[elijahtaylor1, 2014/10/22 16:40:01]

As I stated in the other CL, this is probably ok.  Since WebstoreInstaller
installs the shared modules first, there should be no way for this to fail from
there.  The only downside is that developers side-loading CRXs that forget to
install shared modules first will not get any error warning and the extension
gets into a weird state (delayed I guess), but we are phasing out that workflow

[Joao da Silva, 2014/10/22 18:31:05]

If you agree then it would be great to do this fix for now.

Another possibility is to move the logic that installs the shared_modules out of
the WebstoreInstaller and reuse it for installations via external_loaders too;
only developers loading unpacked extensions should bypass that.

WDYT?

[elijahtaylor1, 2014/10/22 19:57:49]

I don't know much about external_loaders, but if we fixed it this way:  Does
this mean that if you drag-n-drop a CRX that depends on a shared module that is
not installed, that you would download it from the webstore?  I've shied away
from downloading shared modules for users unless the depending extension is also
from the webstore, but that may be unreasonable.

At the very least we can leave this as-is for this CL and file a bug to track
moving the webstoreinstaller code as you described.  Please elaborate on the
external loaders stuff in the bug, as I'm unfamiliar.

[Joao da Silva, 2014/10/23 09:15:02]

I think the drag-and-drop flow is the same as the flow for external providers,
so yes, this would enable the installation of dependencies for CRXes installed
by drap-and-drop.

I've filed a bug to fix this at
https://code.google.com/p/chromium/issues/detail?id=426356.

IMO, extensions installed via external providers should get any dependencies
installed; this includes policy configuration, child accounts, retail-mode
preinstalled extensions, etc.

+          !SharedModuleInfo::IsSharedModule(imported_module)) {
         ReportFailureFromUIThread(CrxInstallerError(l10n_util::GetStringFUTF16(
             IDS_EXTENSION_INSTALL_DEPENDENCY_NOT_SHARED_MODULE,
             base::UTF8ToUTF16(imported_module->name()))));
@@ -508,8 +502,8 @@ void CrxInstaller::CheckInstall() {
             base::ASCIIToUTF16(imported_module->version()->GetString()))));
         return;
       } else if (imported_module &&
-          !SharedModuleInfo::IsExportAllowedByWhitelist(imported_module,
-                                                        extension()->id())) {
+                 !SharedModuleInfo::IsExportAllowedByWhitelist(
+                     imported_module, extension()->id())) {
         ReportFailureFromUIThread(CrxInstallerError(l10n_util::GetStringFUTF16(
             IDS_EXTENSION_INSTALL_DEPENDENCY_NOT_WHITELISTED,
             base::UTF8ToUTF16(extension()->name()),