[RDHI] Refactored blocked_loaders_map_ to key by render frame route id

content/browser/loader/global_routing_id.h

Index: content/browser/loader/global_routing_id.h
diff --git a/content/browser/loader/global_routing_id.h b/content/browser/loader/global_routing_id.h
index df5f202c22e568612508915e54f9fa4d753d83a9..9e6f9e9ebab4e36f37da8ecf0cdbd6070b468083 100644
--- a/content/browser/loader/global_routing_id.h
+++ b/content/browser/loader/global_routing_id.h
@@ -38,6 +38,13 @@ struct GlobalRoutingID {
   }
 };
 
+// Same as GlobalRoutingID except the route_id must be a render frame routing
+// id.
+struct GlobalFrameRoutingID : public GlobalRoutingID {
+  GlobalFrameRoutingID(int child_id, int render_frame_route_id)
+      : GlobalRoutingID(child_id, render_frame_route_id) {}

[Randy Smith (Not in Mondays), 2015/12/29 23:11:36]

Any way to assert that?  Don't we know something about the run time value of the
frame routing ids?

[Charlie Harrison, 2015/12/30 20:51:49]

Hm I'm not quite sure. There was discussion on the site-isolation dev list about
making them distinct from RVIDs at runtime. I think that idea was superseded by
the ID type work.

[Randy Smith (Not in Mondays), 2016/01/04 21:24:48]

Drat; I thought I remembered someone telling me that there were run-time
differences between frame and view ids (even vs. odd) but scanning the code that
doesn't seem to be the case; they both seem to be allocated off
RenderProcessHostImpl::GetNextRoutingId().  So I guess we don't have a good way
to do the assertion :-J.

[Charlie Harrison, 2016/01/04 22:07:43]

I think this was done as a local hack a few times, but I don't think it was ever
landed.

+};
+
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_LOADER_GLOBAL_ROUTING_ID_H_