Implement <webview>.addContentScript/removeContentScript API [1]

extensions/browser/guest_view/web_view/web_view_content_script_manager.h

+// Copyright 2015 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.
+
+#ifndef EXTENSIONS_BROWSER_GUEST_VIEW_WEB_VIEW_WEB_VIEW_CONTENT_SCRIPT_MANAGER_H
+#define EXTENSIONS_BROWSER_GUEST_VIEW_WEB_VIEW_WEB_VIEW_CONTENT_SCRIPT_MANAGER_H
+
+#include <map>
+#include <set>
+#include <string>
+#include <vector>
+
+#include "base/supports_user_data.h"
+
+struct HostID;
+
+namespace content {
+class BrowserContext;
+}
+
+namespace extensions {
+class UserScript;
+
+// WebViewContentScriptManager manages the content scripts that each webview
+// guest adds and removes programmatically.
+class WebViewContentScriptManager : public base::SupportsUserData::Data {

[Devlin, 2015/04/08 17:50:56]

Do we really need this class?  Couldn't adding/removing the content scripts from
the UserScriptMaster and updating the RendererState be done by the api function?

[Xi Han, 2015/04/08 22:10:36]

It is better to have this class to keep other classes clean. The
WebViewInternalAPI is just a glue level, which is responsible for converting the
data from javascript to c++, so it shouldn't know too much about how to handle
these data. Also I try to avoid putting webview-specific code to
UserScriptMaster.

[Devlin, 2015/04/10 16:04:31]

I'm still not entirely convinced of the usefulness/necessity of the class.  Why
would something like:
- API function adds scripts to renderer state
- Renderer state adds content scripts to UserScriptMaster, removes them when
guest is removed
Not work?

My concern is that the lifetime of user scripts is already hard to keep track
of, and I don't know if we want to complicate it yet further.  I think I'd
rather always know that the scripts are owned by the UserScriptMaster.

[Fady Samuel, 2015/04/10 16:44:28]

Devlin, the content scripts are tied to the lifetime of the <webview> tag not
the guest. <webview> tags can gain and lose guests within their own lifetime.
For example, if you remove a webview tag from the DOM, it loses its guest. If
you put it back and set the src attribute, it gets a new guest.
The guest may be created by another guest via window.open, and it only gets a
<webview> as a container on attachment in the new window API:

https://developer.chrome.com/apps/tags/webview#type-NewWindow

[Devlin, 2015/04/10 17:38:57]

Ah, interesting.  So a WebViewInfo is removed when the guest is removed, even
though the web view, in fact, lives on, with the same process and view id?  Is
there a reason we need to remove the WebViewInfo then, as opposed to when the
webview is destroyed (do we know when that is)?

[Xi Han, 2015/04/10 18:27:06]

WebViewInfo contains the routing info for a guest and should be accessed in IO
thread.
In the case that code needs to be run in IO thread, we can access the routing
info for
the guest. If the guest goes away, its routing info doesn't needed anymore, so
we need
to remove the WebViewInfo.

[Devlin, 2015/04/10 18:31:36]

But that routing info is still valid for the next guest (if any) in that
<webview> tag, correct?  So if we add another guest in that same tag, then we
are just recreating a WebViewInfo that we just destroyed, since the routing info
(view id and process id) is linked to the webview tag, not to the guest itself,
right?  So wouldn't it make sense to remove the WebViewInfo when the webview is
destroyed, not when the guest is destroyed?  Even more so when we include
content scripts (as Fady points out, linked to the <webview>, not the guest) on
the WebViewInfo....

+ public:
+  explicit WebViewContentScriptManager(
+      content::BrowserContext* browser_context);
+  ~WebViewContentScriptManager() override;
+
+  static WebViewContentScriptManager* Get(
+      content::BrowserContext* browser_context);
+
+  // Adds content scripts for the guest specified by the |embedder_process_id,
+  // view_instance_id|.
+  // The name of each content sccript is its key in |user_scripts| map.
+  void AddContentScripts(int embedder_process_id,
+                         int view_instance_id,
+                         const HostID& host_id,
+                         const std::map<std::string, UserScript>& user_scripts);
+
+  // Removes contents scipts whose names are in the |script_name_list| for the
+  // guest specified by |embedder_process_id, view_instance_id|.
+  // If the |script_name_list| is empty, removes all the content scripts added
+  // for this guest.
+  void RemoveContentScripts(int embedder_process_id,
+                            int view_instance_id,
+                            const HostID& host_id,
+                            const std::vector<std::string>& script_name_list);
+
+  // Returns whether the content script with |script_id| belonges to the guest
+  // specified by |embedder_process_id, view_instance_id|.
+  bool OwnsUserScript(int embedder_process_id,
+                      int view_instance_id,
+                      int script_id);
+
+  // Returns the content script IDs added by the guest specified by
+  // |embedder_process_id, view_instance_id|.
+  std::set<int> GetContentScriptIDSet(int embedder_process_id,
+                                      int view_instance_id);
+
+ private:
+  using GuestMapKey = std::pair<int, int>;
+  using ContentScriptMap = std::map<std::string, extensions::UserScript>;
+  using GuestContentScriptMap = std::map<GuestMapKey, ContentScriptMap>;
+
+  GuestContentScriptMap guest_content_script_map_;
+
+  content::BrowserContext* browser_context_;
+};
+
+}  // namespace extensions
+
+#endif  // EXTENSIONS_BROWSER_GUEST_VIEW_WEB_VIEW_WEB_VIEW_CONTENT_SCRIPT_MANAGER_H