Pipe the devTools FrameId from blink into the browser for headless

third_party/WebKit/public/web/WebFrameClient.h

Index: third_party/WebKit/public/web/WebFrameClient.h
diff --git a/third_party/WebKit/public/web/WebFrameClient.h b/third_party/WebKit/public/web/WebFrameClient.h
index 7e9100daa5d77423088282c0b5f79b9fd746f9c6..66a70cd0e4ba69e012c233ae43ee9dbbd390773d 100644
--- a/third_party/WebKit/public/web/WebFrameClient.h
+++ b/third_party/WebKit/public/web/WebFrameClient.h
@@ -257,6 +257,9 @@ class BLINK_EXPORT WebFrameClient {
   // Called the first time this frame is the target of a user gesture.
   virtual void SetHasReceivedUserGesture() {}
 
+  // Notification of the devtools id for this frame.
+  virtual void SetDevToolsFrameId(const blink::WebString& devtools_frame_id) {}

[dgozman, 2017/04/25 22:04:48]

I'd prefer content to ask for devtools frame id and send an IPC, instead of
pushing from blink, but I failed to find a place where LocalFrame would already
exist. The best guess was RenderFrameImpl::BindToWebFrame.

@creis: are you aware of a better place?

[Charlie Reis, 2017/04/26 19:52:55]

I agree that it's better for content to ask, to make sure that it goes up at a
consistent time.  Is the idea to do it as early after frame creation as
possible? 

If so, BindToWebFrame may be the right timing, though it feels a bit weird to
put an IPC there.  I suppose it's ok if it's just temporary, until we send the
frame_tree_node_id down.

Note: Whether we do this or the Blink-push approach, the browser process is
still going to have to deal with a window of time where RenderFrameHost doesn't
know the ID yet, including both waiting for the IPC to arrive on the IO thread
and get posted to the UI thread.  Is the headless code that uses it going to
face problems if the ID hasn't arrived yet?

[dgozman, 2017/04/27 17:12:06]

From my understanding, at the time of BindToWebFrame, LocalFrame* may not be
instantiated yet. That's why I failed to find a good place. Perhaps, it doesn't
matter that much if we are 100% sure this is temporary. WDYT?

[Charlie Reis, 2017/04/27 18:58:02]

I don't understand.  BindToWebFrame is passed a LocalFrame that has just been
constructed in each of the three call sites.  Looks like it's not null in
practice when debugging, both for main frames and subframes.  When would it not
be instantiated yet?

I think this is probably the right timing, whether we do it inside that call or
just after each of the call sites.

And if we can, I think we should definitely do it this way, rather than having
Blink push the value up.

[Charlie Reis, 2017/04/27 20:07:34]

Wow, that's some complex initialization!  So we have a WebLocalFrameImpl at the
time of BindToWebFrame but not a LocalFrame inside it, which would explain why
that doesn't work for getting the DevTools frameId.  Sigh.

Unless lfg@ or dcheng@ have any ideas about how RenderFrameImpl can know when
the LocalFrame is created, I guess we have to push the data.  :(

+
   // Console messages ----------------------------------------------------
 
   // Whether or not we should report a detailed message for the given source.