Pass through geofencing API calls to the browser process.

content/child/blink_platform_impl.cc

Index: content/child/blink_platform_impl.cc
diff --git a/content/child/blink_platform_impl.cc b/content/child/blink_platform_impl.cc
index efbe71f21c1650b24554cc2e74cc4b5df64b6ec1..329c8492d2e47d62b99aedb05d2bc60697207467 100644
--- a/content/child/blink_platform_impl.cc
+++ b/content/child/blink_platform_impl.cc
@@ -32,6 +32,7 @@
 #include "content/child/child_thread.h"
 #include "content/child/content_child_helpers.h"
 #include "content/child/fling_curve_configuration.h"
+#include "content/child/geofencing/web_geofencing_provider_impl.h"
 #include "content/child/web_discardable_memory_impl.h"
 #include "content/child/web_socket_stream_handle_impl.h"
 #include "content/child/web_url_loader_impl.h"
@@ -412,7 +413,13 @@ BlinkPlatformImpl::BlinkPlatformImpl()
       shared_timer_fire_time_was_set_while_suspended_(false),
       shared_timer_suspended_(0),
       fling_curve_configuration_(new FlingCurveConfiguration),
-      current_thread_slot_(&DestroyCurrentThread) {}
+      current_thread_slot_(&DestroyCurrentThread) {
+  // ChildThread may not exist in some tests.
+  if (ChildThread::current()) {
+    geofencing_provider_.reset(new WebGeofencingProviderImpl(
+        ChildThread::current()->thread_safe_sender()));
+  }
+}
 
 BlinkPlatformImpl::~BlinkPlatformImpl() {
 }
@@ -995,6 +1002,9 @@ blink::WebCrypto* BlinkPlatformImpl::crypto() {
   return &web_crypto_;
 }
 
+blink::WebGeofencingProvider* BlinkPlatformImpl::geofencingProvider() {

[jochen (gone - plz use gerrit), 2014/09/17 18:26:44]

the WebGeofencingProvider only exists on the main thread, right? Since workers
can't access that directly, why bother with the fancy per thread dispatcher and
filter?

[Marijn Kruisselbrink, 2014/09/18 16:32:05]

No, that's not right. Just like the WebCrypto above, and probably several other
APIs, blink calls these methods on any thread, and thus WebGeofencingProvider
implementations have to be able to deal with its methods being called on
multiple threads as well. To do that I opted to do the same the service worker
code does, with the per-thread dispatcher, and a separate message filter to get
the replies back on the correct thread, but there are of course other ways to
accomplish the same. The WebCrypto code for example just posts messages to a
(renderer side) web crypto thread and deals with crypto stuff there.

So some other possible approaches I could take here to merge
WebGeofencingProviderImpl, GeofencingDispatcher and GeofencingMessageFilter
would involve either routing all API calls through one thread, or somehow using
a thread-safe IDMap to store request.

+  return geofencing_provider_.get();
+}
 
 WebThemeEngine* BlinkPlatformImpl::themeEngine() {
   return &native_theme_engine_;