Don't send unnecessary ExtensionMsg_Loaded IPCs.

extensions/browser/extension_web_contents_observer.cc

Index: extensions/browser/extension_web_contents_observer.cc
diff --git a/extensions/browser/extension_web_contents_observer.cc b/extensions/browser/extension_web_contents_observer.cc
index 04335a527b8531cb9c7e3aac456528117b7be9ad..dec1e531dc262180f6f26e3b08823fa5a864c69d 100644
--- a/extensions/browser/extension_web_contents_observer.cc
+++ b/extensions/browser/extension_web_contents_observer.cc
@@ -90,34 +90,18 @@ void ExtensionWebContentsObserver::RenderViewCreated(
     }
   }
 
-  switch (type) {
-    case Manifest::TYPE_EXTENSION:
-    case Manifest::TYPE_USER_SCRIPT:
-    case Manifest::TYPE_HOSTED_APP:
-    case Manifest::TYPE_LEGACY_PACKAGED_APP:
-    case Manifest::TYPE_PLATFORM_APP:
-      // Always send a Loaded message before ActivateExtension so that
-      // ExtensionDispatcher knows what Extension is active, not just its ID.
-      // This is important for classifying the Extension's JavaScript context
-      // correctly (see ExtensionDispatcher::ClassifyJavaScriptContext).
-      // We also have to include the tab-specific permissions here, since it's
-      // an extension process.
-      render_view_host->Send(
-          new ExtensionMsg_Loaded(std::vector<ExtensionMsg_Loaded_Params>(
-              1, ExtensionMsg_Loaded_Params(
-                     extension, true /* include tab permissions */))));
-      render_view_host->Send(
-          new ExtensionMsg_ActivateExtension(extension->id()));
-      break;
-
-    case Manifest::TYPE_UNKNOWN:
-    case Manifest::TYPE_THEME:
-    case Manifest::TYPE_SHARED_MODULE:
-      break;
-
-    case Manifest::NUM_LOAD_TYPES:
-      NOTREACHED();
-  }
+  // Tells the new view that it's hosted in an extension process. It would be
+  // better to do this at process creation time (RendererStartupHelper), but
+  // the information that it's an *extension* process isn't plumbed in.
+  //
+  // Note that because this code is run per *view* we may end up sending

[Devlin, 2015/06/03 20:53:37]

I think more important is that the Dispatcher is keyed to the RenderThread,
which can (AFAIK) outlive views, but we never de-activate an extension.  So any
number of extensions could be active.

That said, I think we should also look into removing this ActivateExtension
thingy.  It's weird, and not used very much.

[not at google - send to devlin, 2015/06/03 21:53:03]

The comment is about the fact that extension activation can only happen on
render process (host) creation, so we'd potentially save some IPCs by doing it
there.

It's less related about the *other* weirdness where this activated extension set
is stored process-wide rather than on the process abstraction level. Unless
RenderThread is a process abstraction...? I don't know. Anyway I'll update the
comment to make it more obvious that it's about saving IPCs.
It's important at the moment, but it won't be necessary with site isolation.
That will be a good time to delete it.

+  // multiple redundant ExtensionMsg_ActivateExtension messages. For example,
+  // opening a popup will load both the background page and the popup, 2 views.
+  //
+  // All of the above said, the concept of activating an extension should be
+  // moot when site isolation is able to guarantee that no extension iframe can
+  // live in an untrusted process.
+  render_view_host->Send(new ExtensionMsg_ActivateExtension(extension->id()));
 }
 
 void ExtensionWebContentsObserver::RenderFrameCreated(