Support webview tag in component extension

chrome/renderer/extensions/dispatcher.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/renderer/extensions/dispatcher.h"
 
 #include "base/callback.h"
 #include "base/command_line.h"
 #include "base/debug/alias.h"
 #include "base/json/json_reader.h"
@@ skipping 460 matching lines @@
 
   // Initialize host permissions for any extensions that were activated before
   // WebKit was initialized.
   for (std::set<std::string>::iterator iter = active_extension_ids_.begin();
        iter != active_extension_ids_.end(); ++iter) {
     const Extension* extension = extensions_.GetByID(*iter);
     CHECK(extension);
     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;
 }
 
 void Dispatcher::IdleNotification() {
   if (is_extension_process_) {
     // Dampen the forced delay as well if the extension stays idle for long
     // periods of time.
     int64 forced_delay_ms = std::max(
         RenderThread::Get()->GetIdleNotificationDelayInMs(),
@@ skipping 610 matching lines @@
   }
 
   if (context_type == Feature::BLESSED_EXTENSION_CONTEXT &&
       is_within_platform_app &&
       GetCurrentChannel() <= chrome::VersionInfo::CHANNEL_DEV &&
       CommandLine::ForCurrentProcess()->HasSwitch(
           switches::kEnableAppWindowControls)) {
     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)) {
       module_system->Require("webView");
       bool includeExperimental =
           GetCurrentChannel() <= chrome::VersionInfo::CHANNEL_DEV ||
           extension->id() == extension_misc::kIdentityApiUiAppId;
       if (!includeExperimental) {
         // TODO(asargent) We need a whitelist for webview experimental.
         // crbug.com/264852
@@ skipping 113 matching lines @@
   if (is_webkit_initialized_) {
     InitOriginPermissions(extension);
     // DOMActivity logger for a main world controlled by an extension (as in
     // the case of an extension background page, options page, popup etc.)
     // gets an empty title.
     DOMActivityLogger::AttachToWorld(DOMActivityLogger::kMainWorldId,
                                      extension_id,
                                      extension->url(),
                                      string16());
 
-    if (IsWithinPlatformApp())
-      EnableCustomElementWhiteList();
+    EnableCustomElementWhiteList();
   }
 }
 
 void Dispatcher::InitOriginPermissions(const Extension* extension) {
   // TODO(jstritar): We should try to remove this special case. Also, these
   // whitelist entries need to be updated when the kManagement permission
   // changes.
   if (extension->HasAPIPermission(APIPermission::kManagement)) {
     WebSecurityPolicy::addOriginAccessWhitelistEntry(
         extension->url(),
@@ skipping 299 matching lines @@
     RenderView* background_view =
         ExtensionHelper::GetBackgroundPage(extension_id);
     if (background_view) {
       background_view->Send(new ExtensionHostMsg_EventAck(
           background_view->GetRoutingID()));
     }
   }
 }
 
 }  // namespace extensions