Add CWVUserContentController which enables injecting JavaScripts.

ios/web_view/internal/web_view_early_page_script_provider.mm

+// Copyright 2017 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.
+
+#import "ios/web_view/internal/web_view_early_page_script_provider.h"
+
+#import <Foundation/Foundation.h>
+
+#include "ios/web/public/browser_state.h"
+
+#if !defined(__has_feature) || !__has_feature(objc_arc)
+#error "This file requires ARC support."
+#endif
+
+namespace ios_web_view {
+
+namespace {
+// A key used to associate a WebViewEarlyPageScriptProvider with a BrowserState.
+const char kWebViewEarlyPageScriptProviderKeyName[] =
+    "web_view_early_page_script_provider";
+
+}  // namespace
+
+// static
+WebViewEarlyPageScriptProvider&
+WebViewEarlyPageScriptProvider::FromBrowserState(
+    web::BrowserState* browser_state) {
+  DCHECK([NSThread isMainThread]);

[michaeldo, 2017/03/21 16:12:34]

Why is this bound to the main thread? Should we DCHECK against one of the
WebThread constants instead? If so, please update comment in header.

For example, DCHECK_CURRENTLY_ON(WebThread::UI)

(macro defined in ios/web/public/web_thread.h)

[Hiroshi Ichikawa, 2017/03/22 04:52:52]

Well, I just copied implementation of:
https://cs.chromium.org/chromium/src/ios/web/web_state/ui/wk_web_view_configu...
I believe the check is needed because the class is not safe against access from
multiple threads.
Used DCHECK_CURRENTLY_ON(WebThread::UI) instead.

[michaeldo, 2017/03/22 23:03:32]

Got it, that makes sense, either is likely ok. However, maybe some of the WebKit
calls require mainThread explicity which could be the reason to use NSThread
instead.

+  DCHECK(browser_state);
+  if (!browser_state->GetUserData(kWebViewEarlyPageScriptProviderKeyName)) {
+    browser_state->SetUserData(kWebViewEarlyPageScriptProviderKeyName,
+                               std::unique_ptr<WebViewEarlyPageScriptProvider>(

[michaeldo, 2017/03/21 16:12:34]

please use base::MakeUnique instead of new

[Hiroshi Ichikawa, 2017/03/22 04:52:52]

MakeUnique() causes an error in this case because the constructor of this class
is currently private so MakeUnique() cannot access the constructor. Should I
make the constructor public?

[michaeldo, 2017/03/22 23:03:32]

I see, no using new is OK then. However, is the std::unique_ptr needed at all,
in the link above to wk_web_view_configuration_provider.mm, it doesn't have the
std::unique_ptr wrapper

[Hiroshi Ichikawa, 2017/03/23 02:18:40]

That's true. But I found this comment:
https://cs.chromium.org/chromium/src/base/supports_user_data.h?l=40&rcl=89365...
So I assumed using the version which takes a raw pointer is not recommended.

+                                   new WebViewEarlyPageScriptProvider()));
+  }
+  return *(static_cast<WebViewEarlyPageScriptProvider*>(
+      browser_state->GetUserData(kWebViewEarlyPageScriptProviderKeyName)));
+}
+
+WebViewEarlyPageScriptProvider::WebViewEarlyPageScriptProvider() {

[Eugene But (OOO till 7-30), 2017/03/21 16:47:55]

WebViewEarlyPageScriptProvider::WebViewEarlyPageScriptProvider() :
script_([[NSString ] init]) {}

[Hiroshi Ichikawa, 2017/03/22 04:52:52]

Done. But just curious, why? Is [[NSString alloc] init] preferred to @""?

[Eugene But (OOO till 7-30), 2017/03/22 15:08:50]

Sorry, my comment was mostly about using initialization list. There is probably
no practical different between |[[NSString alloc] init]| and |@""|.

[Hiroshi Ichikawa, 2017/03/23 02:18:40]

Thanks for clarification!

+  script_ = @"";
+}
+
+WebViewEarlyPageScriptProvider::~WebViewEarlyPageScriptProvider() {}

[michaeldo, 2017/03/21 16:12:34]

please use "= default;" instead of {}

[Hiroshi Ichikawa, 2017/03/22 04:52:52]

Done.

+
+}  // namespace ios_web_view