[TimeZoneMonitor] Decouple renderer side impl from content to blink.

third_party/WebKit/public/web/WebKit.h

Index: third_party/WebKit/public/web/WebKit.h
diff --git a/third_party/WebKit/public/web/WebKit.h b/third_party/WebKit/public/web/WebKit.h
index ddb13d9351f33b75946d3c056abd696d147e9d33..13995d6b68b4de69d83efdf1d951aa9b34cd4c13 100644
--- a/third_party/WebKit/public/web/WebKit.h
+++ b/third_party/WebKit/public/web/WebKit.h
@@ -44,6 +44,19 @@ namespace blink {
 // non-null and must remain valid until the current thread calls shutdown.
 BLINK_EXPORT void initialize(Platform*);
 
+// Blink's mojo stuff must be initialized with 2 prerequisites:

[blundell, 2016/10/18 12:32:11]

Ah I see, this is where you added the comment. Great, exactly what I was
envisioning.

+//   1, Mojo edk initialized;
+//   2, A message loop is ready for current thread.
+// For production code it's sure that above 2 are already fullfilled before

[blundell, 2016/10/18 12:32:11]

This comment strengthens my belief that we should name this method
initializeMojoForTesting().

[leonhsl(Using Gerrit), 2016/10/18 14:34:48]

Acknowledged.

[leonhsl(Using Gerrit), 2016/10/19 08:47:23]

Done. Referring the naming practice of other APIs in this file, changed the name
to initializeMojoForTest().

+// calling blink::initialize(), so the mojo stuff will be initialized along with
+// other stuff(platform, core, modules etc.) as well. But this could be no for
+// some test codes, when they call blink::initialize() maybe they have not
+// gotten Mojo edk or message loop ready yet, maybe they would fullfill the
+// above 2 prerequisites later according with their code logic, in such case we
+// provide this API to give them another opportunity to initialize the mojo
+// stuff, which has been skipped by blink::initialize().

[haraken, 2016/10/18 19:39:11]

Hmm, would you summarize why you cannot just use initialize() to initialize
Mojo?

We really want to centralize all initialization paths to WebKit::initialize().
(I've done a lot of refactoring to centralize distributed initialization paths
before.)

[leonhsl(Using Gerrit), 2016/10/19 08:47:23]

Inside Blink, as about the mojo stuff that must be initialized along with Blink
initialization, for now the only piece is our newly created 
TimezoneMonitorClient, its instantiation would do some mojo message pipe
operations such as getting remote interface and binding local interface ptr,
mojo edk init and a message loop for current thread are *necessary* to these
operations.
For production code, blink::initialize() would initiate TimezoneMonitorClient
without problem, but for some test codes blink::initialize() would skip
TimezoneMonitorClient initialization because message loop may be not ready yet,
later, if message loop got ready and the test codes need the
TimezoneMonitorClient, then it could call our newly provided API
blink::initializeMojoForTest() to initialize TimezoneMonitorClient again.

+BLINK_EXPORT void initializeMojo();
+
 // Get the V8 Isolate for the main thread.
 // initialize must have been called first.
 BLINK_EXPORT v8::Isolate* mainThreadIsolate();