Thanks for reporting this.

My hunch is that this is likely the subframe equivalent of 'RenderViewReady': the TM likely tracks a RenderFrameCreated() event for the reloaded subframe, but at that moment in time, we don't have a pid for the subprocess.

If so, then we can fix this by using RenderProcessHostObserver from inside the TM (RenderViewReady is really just a forwarded RPHO event). We could also consider adding a per-frame variant of RenderViewReady to WebContentsObserver (ideally dropping RenderViewReady at the same time). Doing that would require taking a look at the various reasons observers are listening to RenderViewReady today.

 Issue 678755  has been merged into this issue.

 Issue 697135  has been merged into this issue.

Right now task_manager::WebContentsEntry listens for RenderFrameHostChanged and RenderFrameDeleted, but doesn't listen for RenderFrameCreated (fired for the recreated processes).  Listening for RenderFrameCreated doesn't immediately help, because (as nick@ says in #c1) we don't have a task id at this point (leading to task manager thinking that the new task/entry has pid=0).

I have a draft of a fix at https://codereview.chromium.org/2857263003.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f2c4f1f94d10b019363f2d8c45defe00881cb5cb

commit f2c4f1f94d10b019363f2d8c45defe00881cb5cb
Author: lukasza <lukasza@chromium.org>
Date: Wed May 17 04:35:50 2017

Task Manager should listen to WebContentsObserver::RenderFrameCreated.

Listening to WebContentsObserver::RenderFrameCreated is the only way to
realize that a RenderFrameHost got recreated after a render process
crash - Task Manager needs to listen to this callback to re-show frames
that were re-navigated after a render process crash.

A slight problem with this approach is that the PID of the render
process is not necessarily known when RenderFrameCreated is called - to
work around that Task Manager postpones processing of the new frame via
PostTaskWhenProcessIsReady (an instance method added to RenderProcessHost
in this CL).

BUG= 642958 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2857263003
Cr-Commit-Position: refs/heads/master@{#472325}

[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/chrome/browser/task_manager/providers/web_contents/web_contents_task_provider.cc
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/chrome/browser/task_manager/task_manager_browsertest.cc
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/browser/renderer_host/render_view_host_impl.h
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/public/browser/render_frame_host.h
[modify] https://crrev.com/f2c4f1f94d10b019363f2d8c45defe00881cb5cb/content/public/browser/render_process_host.h

I've tested the repro steps
- on 60.0.3104.0 (branch_base_position=473014, so it includes the fix from #c7)
- with chrome://flags/#enable-site-per-process
and the issue seems to be fixed.