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

content/browser/loader/global_routing_id.h

 // 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.
 
 #ifndef CONTENT_BROWSER_LOADER_GLOBAL_ROUTING_ID_H_
 #define CONTENT_BROWSER_LOADER_GLOBAL_ROUTING_ID_H_
 
 #include <tuple>
 
 namespace content {
@@ skipping 20 matching lines @@
   }
   bool operator==(const GlobalRoutingID& other) const {
     return child_id == other.child_id &&
         route_id == other.route_id;
   }
   bool operator!=(const GlobalRoutingID& other) const {
     return !(*this == other);
   }
 };
 
+// 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_