Content API changes to improve DOM stitching in ThreatDetails code.

content/public/browser/render_frame_host.h

Index: content/public/browser/render_frame_host.h
diff --git a/content/public/browser/render_frame_host.h b/content/public/browser/render_frame_host.h
index 72cbc18bbafaea6d07ae5e29f5e9c42fc69c5d0a..b7245f1f965575eb0852e9d414dc9b704d31418f 100644
--- a/content/public/browser/render_frame_host.h
+++ b/content/public/browser/render_frame_host.h
@@ -63,6 +63,12 @@ class CONTENT_EXPORT RenderFrameHost : public IPC::Listener,
   // Returns a RenderFrameHost given its accessibility tree ID.
   static RenderFrameHost* FromAXTreeID(int ax_tree_id);
 
+  // Returns the RenderFrameHost corresponding to the specified |process_id| and
+  // |routing_id|. This host may represent a placeholder for a frame that is
+  // currently rendered in a different process than |process_id|.

[Charlie Reis, 2017/05/10 22:17:49]

Hmm, I really prefer the previous version of the API that returned a
FrameTreeNode ID, which looks like it would be sufficient for your use case in
ThreatDetails::OnReceivedThreatDOMDetails.

The problem with the current API is that it's too easy for callers to assume
that the RenderFrameHost returned here is actually in |process_id|, since that's
the value they passed in to look it up.  That could very easily lead to security
bugs where we assume a frame has access to something that it does not.

Can we switch back to GetFrameTreeNodeIdForRoutingId?

[lpz, 2017/05/12 13:53:16]

Done.

+  static RenderFrameHost* GetRenderFrameHostForRoutingId(int process_id,
+                                                         int routing_id);
+
   ~RenderFrameHost() override {}
 
   // Returns the route id for this frame.