Pipe the devTools FrameId from blink into the browser for headless

third_party/WebKit/public/web/WebFrameClient.h

 /*
  * Copyright (C) 2011, 2012 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 239 matching lines @@
                                              const WebFrameOwnerProperties&) {}
 
   // Called when a watched CSS selector matches or stops matching.
   virtual void DidMatchCSS(
       const WebVector<WebString>& newly_matching_selectors,
       const WebVector<WebString>& stopped_matching_selectors) {}
 
   // 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.
   virtual bool ShouldReportDetailedMessageForSource(const WebString& source) {
     return false;
   }
 
   // A new message was added to the console.
   virtual void DidAddMessageToConsole(const WebConsoleMessage&,
                                       const WebString& source_name,
@@ skipping 496 matching lines @@
   // Overwrites the given URL to use an HTML5 embed if possible.
   // An empty URL is returned if the URL is not overriden.
   virtual WebURL OverrideFlashEmbedWithHTML(const WebURL& url) {
     return WebURL();
   }
 };
 
 }  // namespace blink
 
 #endif