Remove 2-stage RenderWidget initialization

content/public/browser/render_process_host.h

Index: content/public/browser/render_process_host.h
diff --git a/content/public/browser/render_process_host.h b/content/public/browser/render_process_host.h
index e7d35a7f42eba82f06ebc67b8deaec8aaa071574..a2bf27f600d96a578f6884d78291cb0f84eb45e7 100644
--- a/content/public/browser/render_process_host.h
+++ b/content/public/browser/render_process_host.h
@@ -114,8 +114,10 @@ class CONTENT_EXPORT RenderProcessHost : public IPC::Sender,
 
   // Try to shut down the associated renderer process without running unload
   // handlers, etc, giving it the specified exit code. If |wait| is true, wait
-  // for the process to be actually terminated before returning.
-  // Returns true if it was able to shut down.
+  // for the process to be actually terminated before returning.  Returns true
+  // if it was able to shut down.  On Windows, this must not be called before
+  // RenderProcessReady was called on a RenderProcessHostObserver, otherwise
+  // RenderProcessExited may never be called.

[ncarter (slow), 2015/09/29 18:28:40]

Is there a DCHECK that catches this case? (If not, this might be another reason
to consider adding an explicit render_process_ready_ bool to
RenderProcessHostImpl).

[piman, 2015/09/29 23:54:27]

There's not, and I considered it, but I did not add one. Calling Shutdown is
still valid even if the channel is not connected, the only thing is that we rely
on the channel error to report RenderProcessExited, and on Windows we only see a
channel error if the channel was connected. But Shutdown will still kill the
process (assuming it was started), and there is no difference if there is no
observer.

Note that I'm not changing behavior here (just documenting existing logic).

   virtual bool Shutdown(int exit_code, bool wait) = 0;
 
   // Try to shut down the associated renderer process as fast as possible.
@@ -133,9 +135,15 @@ class CONTENT_EXPORT RenderProcessHost : public IPC::Sender,
   //
   // NOTE: this is not necessarily valid immediately after calling Init, as
   // Init starts the process asynchronously.  It's guaranteed to be valid after
-  // the first IPC arrives.
+  // the first IPC arrives or RenderProcessReady was called on a
+  // RenderProcessHostObserver for this. At that point, IsReady() returns true.
   virtual base::ProcessHandle GetHandle() const = 0;
 
+  // Returns whether the process is ready. The process is ready once it is
+  // launched and the channel is connected. At that point, GetHandle() is valid,

[ncarter (slow), 2015/09/29 18:28:40]

I'm on the fence here, as to whether it's better to keep things simple and say
"Process is launched", or be more explicit, like, "the process launcher reported
a successful launch" or "the process launcher reported back a valid process
handle". With the simple wording it's not clear that the two conditions can
happen in either order. I'll leave it up to you.

[piman, 2015/09/29 23:54:27]

Ok, I clarified a bit in the latest PS.

+  // and deferred messages have been sent.
+  virtual bool IsReady() const = 0;
+
   // Returns the user browser context associated with this renderer process.
   virtual content::BrowserContext* GetBrowserContext() const = 0;