Chrome side of passing on the service worker registration with geofencing API calls.

content/browser/renderer_host/render_process_host_impl.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.
 
 // Represents the browser side of the browser <--> renderer communication
 // channel. There will be one RenderProcessHost per renderer process.
 
 #include "content/browser/renderer_host/render_process_host_impl.h"
 
 #include <algorithm>
@@ skipping 875 matching lines @@
       switches::kEnableMemoryBenchmarking))
     AddFilter(new MemoryBenchmarkMessageFilter());
 #endif
   AddFilter(new VibrationMessageFilter());
   AddFilter(new PushMessagingMessageFilter(
       GetID(), storage_partition_impl_->GetServiceWorkerContext()));
   AddFilter(new BatteryStatusMessageFilter());
 #if defined(OS_ANDROID)
   AddFilter(new ScreenOrientationMessageFilterAndroid());
 #endif
-  AddFilter(new GeofencingDispatcherHost(browser_context_));
+  AddFilter(
+      new GeofencingDispatcherHost(browser_context_, service_worker_filter));

[Michael van Ouwerkerk, 2014/10/09 12:28:09]

This should pass in storage_partition_impl_->GetServiceWorkerContext() instead
of the filter.

[Marijn Kruisselbrink, 2014/10/09 22:28:59]

That's not enough. To go from registration handle ID to RegistrationHandle (and
eventually to Registration) some renderer process specific state is necessary,
and currently that state only lives in ServiceWorkerDispatcherHost. So either
the IPC would have to use some other identifier, the mapping from handle id to
handle would have to live in a different object, or some other way of exposing
this mapping is needed.

[michaeln, 2014/10/13 00:32:49]

Kinda messy, no?

I'm not sure the mapping is needed at all. Looks like what you want is the
registraion id and the origin, and that the indirection with handle ids is
getting in the way. There's a bug open about cleaning up how the peer objects
are maintained between the renderer/browser processes (crbug/384119).

I'd vote to arrange something here that is in keeping with the direction
outlined in that cleanup, but w/o having done all of the cleanup. That cleanup
suggests getting rid of handle_ids, so how about we use registration_id as the
message param for this stuff. In that case, sw_context is sufficient to retrieve
a ServiceWorkerRegistration instance given a registration_id and to get is
origin.

The renderer side data structures currently don't store the registration_id
value. I think we could include that value in the
ServiceWorkerRegistrationObjectInfo struct and use it in place of handle_id for
the geofencing messages. On the browser side, you should be able to use
context_->GetLiveRegistration(id) and expect a non-null value back since the
messages your handling are method calls on a registration object which implies a
live instance.

Wdyt, less messy?

[Marijn Kruisselbrink, 2014/10/13 19:29:48]

Yes, that sounds much better. I've now changed it to use the registration_id
directly for all geofencing IPCs.

 }
 
 int RenderProcessHostImpl::GetNextRoutingID() {
   return widget_helper_->GetNextRoutingID();
 }
 
 
 void RenderProcessHostImpl::ResumeDeferredNavigation(
     const GlobalRequestID& request_id) {
   widget_helper_->ResumeDeferredNavigation(request_id);
@@ skipping 1343 matching lines @@
   if (worker_ref_count_ == 0)
     Cleanup();
 }
 
 void RenderProcessHostImpl::EnsureMojoActivated() {
   mojo_activation_required_ = true;
   MaybeActivateMojo();
 }
 
 }  // namespace content