Support webview tag in component extension

chrome/renderer/extensions/dispatcher.cc

Index: chrome/renderer/extensions/dispatcher.cc
diff --git a/chrome/renderer/extensions/dispatcher.cc b/chrome/renderer/extensions/dispatcher.cc
index 7ed9437eb12539c5f71807233a45a6d0d2980ca6..a9ca2263bfb156fc8c63f285f43134ff25046de9 100644
--- a/chrome/renderer/extensions/dispatcher.cc
+++ b/chrome/renderer/extensions/dispatcher.cc
@@ -478,8 +478,7 @@ void Dispatcher::WebKitInitialized() {
     InitOriginPermissions(extension);
   }
 
-  if (IsWithinPlatformApp())

[Charlie Reis, 2013/09/04 17:47:29]

Removing this seems concerning.  We don't want the whitelist in every extension,
do we?

[guohui, 2013/09/05 19:35:04]

In an earlier prototype CL, Fady mentioned that it may be ok to remove the check
(and the one below), because document.register is no longer exposed.

@fady, could you please confirm?

[Fady Samuel, 2013/09/09 16:30:49]

Yea, document_natives is not exposed to third party developers.

[guohui, 2013/09/09 16:43:00]

thanks fady, then is there any other unwanted side effect by removing this
check?

[Fady Samuel, 2013/09/09 17:35:05]

None come to mind, but I'm not entirely certain. It's worth confirming with
dominicc@. 

WebKit::WebRuntimeFeatures::enableEmbedderCustomElements(true); ought to be OK
even in extensions. It doesn't enable document.register. It just enables
creating custom elements via custom bindings: DocumentNatives.RegisterElement.

[dominicc (has gone to gerrit), 2013/09/10 02:50:49]

The side effect will be that any element names you're using (eg webview) will
have HTMLElement as their interface instead of HTMLUnknownElement.

This is detectable (by examining the prototype or doing instanceof) but since
HTMLUnknownElement doesn't add any extra operations or attributes, it probably
won't break much.

Just out of curiosity, is there any guarantee that the setup code runs before
web content?

[guohui, 2013/09/12 20:27:27]

today EnableCustomElementWhiteList is called in two places WebKitInitialized and
OnActivateExtension. I think WebKitInitialized is always called before
OnActivateExtension and before any web content is rendered, thus it is
guaranteed that the setup code runs b4 web content and we don't really need to
call EnableCustomElementWhiteList in OnActivateExtension.

@fady, what do you think?

-    EnableCustomElementWhiteList();
+  EnableCustomElementWhiteList();
 
   is_webkit_initialized_ = true;
 }
@@ -1110,11 +1109,10 @@ void Dispatcher::DidCreateScriptContext(
     module_system->Require("windowControls");
   }
 
-  // Only platform apps support the <webview> tag, because the "webView" and
-  // "denyWebView" modules will affect the performance of DOM modifications
-  // (http://crbug.com/196453).
-  if (context_type == Feature::BLESSED_EXTENSION_CONTEXT &&
-      is_within_platform_app) {
+  // Currently only platform apps and component extensions support the <webview>
+  // tag, because the "webView" and "denyWebView" modules will affect the
+  // performance of DOM modifications (http://crbug.com/196453).
+  if (context_type == Feature::BLESSED_EXTENSION_CONTEXT) {
     // Note: setting up the WebView class here, not the chrome.webview API.
     // The API will be automatically set up when first used.
     if (extension->HasAPIPermission(APIPermission::kWebView)) {
@@ -1248,8 +1246,7 @@ void Dispatcher::OnActivateExtension(const std::string& extension_id) {
                                      extension->url(),
                                      string16());
 
-    if (IsWithinPlatformApp())
-      EnableCustomElementWhiteList();
+    EnableCustomElementWhiteList();
   }
 }