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

content/browser/renderer_host/render_process_host_impl.cc

Index: content/browser/renderer_host/render_process_host_impl.cc
diff --git a/content/browser/renderer_host/render_process_host_impl.cc b/content/browser/renderer_host/render_process_host_impl.cc
index 1bf8bd15e50960a6680a64191c3ba4af0bdc0ad3..a215acd1196a6051ec8ec36323d50ab54cdf3306 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -893,7 +893,8 @@ void RenderProcessHostImpl::CreateMessageFilters() {
 #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() {