Remove a use of NOTIFICATION_RENDERER_PROCESS_CREATED.

Remove a use of NOTIFICATION_RENDERER_PROCESS_CREATED.

BUG=170921
TEST=no change

[Avi (use Gerrit), 2013-11-14 00:26:27]

I don't understand the use of NOTIFICATION_RENDERER_PROCESS_CREATED here.

It's catching the case where:
- A WebContents is somehow using a renderer without
NOTIFICATION_RENDER_VIEW_HOST_CHANGED having been fired, and then
- NOTIFICATION_RENDERER_PROCESS_CREATED is fired to indicate that the renderer
that the WebContents is _currently_using_ was just created.

What is that scenario? If it exists I will fix
NOTIFICATION_RENDER_VIEW_HOST_CHANGED. If it does not exist this code is not
helpful.

[joth, 2013-11-14 01:16:07]

+ppi this notification is mostly relevant to your bindAsHighPriority() work so
over to you for initial review.

[ppi, 2013-11-14 11:27:42]

Thanks, Jonathan!

Avi, we listen to these notifications to keep track of the pid of the renderer
process that backs our ContentView.

When a new RenderViewHost is created and we receive the RENDER_VIEW_HOST_CHANGED
notification (e.g. upon opening a new tab or hitting "reload" on a crashed one),
the renderer pid is not (necessarily?) available, and we (can?) get 0 when
calling GetRenderProcessIdFromRenderViewHost().

In these scenarios RENDERER_PROCESS_CREATED follows RENDER_VIEW_HOST_CHANGED and
it is delivered when the process is already spawned, so we can take note of its
pid.

As for the RENDER_VIEW_HOST_CHANGED notification, we still need it for the
prerendering scenario, to take note of the change from one render view host with
live render process to another.

Please let me know if this makes any sense and I can be of any further help.

[Avi (use Gerrit), 2013-11-21 20:39:55]

On 2013/11/14 11:27:42, ppi wrote:
> Thanks, Jonathan!
> 
> Avi, we listen to these notifications to keep track of the pid of the renderer
> process that backs our ContentView.
> 
> When a new RenderViewHost is created and we receive the
RENDER_VIEW_HOST_CHANGED
> notification (e.g. upon opening a new tab or hitting "reload" on a crashed
one),
> the renderer pid is not (necessarily?) available, and we (can?) get 0 when
> calling GetRenderProcessIdFromRenderViewHost().
> 
> In these scenarios RENDERER_PROCESS_CREATED follows RENDER_VIEW_HOST_CHANGED
and
> it is delivered when the process is already spawned, so we can take note of
its
> pid.
> 
> As for the RENDER_VIEW_HOST_CHANGED notification, we still need it for the
> prerendering scenario, to take note of the change from one render view host
with
> live render process to another.
> 
> Please let me know if this makes any sense and I can be of any further help.

That makes sense. Let me think about this a bit more...

[Avi (use Gerrit), 2013-11-21 21:00:31]

On 2013/11/14 11:27:42, ppi wrote:
> When a new RenderViewHost is created and we receive the
RENDER_VIEW_HOST_CHANGED
> notification (e.g. upon opening a new tab or hitting "reload" on a crashed
one),
> the renderer pid is not (necessarily?) available, and we (can?) get 0 when
> calling GetRenderProcessIdFromRenderViewHost().

Isn't that what WebContentsObserver::RenderViewReady() is for?

The docs on that call suck, but it's the equivalent of
NOTIFICATION_WEB_CONTENTS_CONNECTED. To quote that documentation:

  // This notification is sent when a render view host has connected to a
  // renderer process.

Plus you _already_ call all the way into the Java code for that
(Java_ContentViewCore_onWebContentsConnected), so the plumbing is there.

I will send you a CL, but further work might be necessary.