Attaching videos for reference.

Deleted: Expected.ogv 1.8 MB

Expected.ogv 1.8 MB Download

Deleted: Actual-1.ogv 1.6 MB

Actual-1.ogv 1.6 MB Download

Reproducible on the latest canary(51.0.2668.0) on Mac OS 10.11.3 as well.

Needs-Triage label for finding an owner for this.

Adding creis@ and myself to this. The repro steps hit a DCHECK in WebContentsImpl::UpdateState:

[126410:126410:0304/132333:FATAL:web_contents_impl.cc(4037)] Check failed: entry == new_entry (0x619000ae5180 vs. (nil))
#0 0x7fca270aad61 __interceptor_backtrace
#1 0x7fca256a1b43 base::debug::StackTrace::StackTrace()
#2 0x7fca2570c2cb logging::LogMessage::~LogMessage()
#3 0x7fca1dbe0551 content::WebContentsImpl::UpdateState()
#4 0x7fca1d897d3b content::RenderViewHostImpl::OnUpdateState()
#5 0x7fca1d8965a9 content::RenderViewHostImpl::OnMessageReceived()
#6 0x7fca1d8a73ec content::RenderWidgetHostImpl::OnMessageReceived()
#7 0x7fca1d86c605 content::RenderProcessHostImpl::OnMessageReceived()
#8 0x7fca1b09f0b0 IPC::ChannelProxy::Context::OnDispatchMessage()
#9 0x7fca256a52f2 base::debug::TaskAnnotator::RunTask()
...

Thank you nasko@ for looking into this.

 sc00335628@ Are you still able to reproduce ? If not please mark as Wont'Fix.

This looks like an important bug that affects more than just view-source and chrome:// URLs.  We don't seem to be able to create a RenderFrame when going back/forward cross-process.

(Also the DCHECK from comment 4 isn't repro'ing for me at the moment, probably because we've enabled UseSubframeNavigationEntries.)

More general repro steps:
1) Visit http://csreis.github.io/tests/window-open.html
2) Click "Open simple window"
3) In the new window, navigate to http://www.chromium.org (cross-process).
4) In the task manager, kill the Chromium process.
5) Go back.  (The simple.html page should be shown, but it isn't.)
6) Go forward.  (chromium.org successfully renders.)
7) Go back again.  (We still see Aw Snap for simple.html.)

Alex is investigating a similar issue with RenderFrames, so hopefully he can take a look.

Yes, I'll take a look.  I've confirmed this is still a problem after my fixes for issues  634368 , 627400, and 627893.  Also, interestingly, the favicon in step 6 still shows sad tab even though chromium.org successfully renders, and even hitting reload doesn't get rid of it.

It appears that the following code in RFHM::UpdateStateForNavigate causes the bug:

    // Check if our current RFH is live before we set up a transition.
    if (!render_frame_host_->IsRenderFrameLive()) {
      // The current RFH is not live.  There's no reason to sit around with a
      // sad tab or a newly created RFH while we wait for the pending RFH to
      // navigate.  Just switch to the pending RFH now and go back to normal.
      // (Note that we don't care about on{before}unload handlers if the current
      // RFH isn't live.)
      CommitPending();
      return render_frame_host_.get();
    }

Commenting this out makes all aspects of the bug go away.  Not sure why yet.

This is just an optimization to hide the sad tab faster, right?  Not sure if it's worth the added complexity.

Huh, that's been there forever.  We can probably get by without it (though we should probably test that case to make sure it behaves ok), but I'm very curious how it leads to this bug.  Anyway, nice find.

OK, after some more investigation, the actual reason for the bug is a bit different: we are not dispatching WCO::RenderViewReady for a RenderViewHost that's reused and changes state from swapped out to active.  This is exactly the setup after step 5 in the #7 repro.  Thus, SadTabHelper::RenderViewReady, which is what hides the sad tab, is never called.

The reason why removing the early CommitPending in #9 makes things work, is because it allows the following code to then run in RFHM::Navigate:

  // If the current render_frame_host_ isn't live, we should create it so
  // that we don't show a sad tab while the dest_render_frame_host fetches
  // its first page.  (Bug 1145340)
  if (dest_render_frame_host != render_frame_host_.get() &&
      !render_frame_host_->IsRenderFrameLive()) {
    // Note: we don't call InitRenderView here because we are navigating away
    // soon anyway, and we don't have the NavigationEntry for this host.
    delegate_->CreateRenderViewForRenderManager(
        render_frame_host_->render_view_host(), MSG_ROUTING_NONE,
        MSG_ROUTING_NONE, frame_tree_node_->current_replication_state());
  }

(With #9's CommitPending in place, dest_render_frame_host is the same as render_frame_host_.)

This essentially recreates the process for the old RVH while we're waiting for the new navigation to finish, and if that process starts up before we destroy it again after the navigation finishes, it triggers RenderViewReady (via RVHI::RenderProcessReady) which hides the sad tab.  However, if the navigation finishes first, things still won't work (and indeed, the test I have written for this is flaky precisely because of this).  So, I think for the fix, we can keep the early CommitPending and instead dispatch a RenderViewReady when a RVH transitions from swapped out to active.

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

commit 61e1fcd02e595f2e882f9e702f69f3363ca9ae6b
Author: alexmos <alexmos@chromium.org>
Date: Thu Aug 11 23:28:47 2016

Send RenderViewReady when a RVH is reused and becomes active.

Normally, RenderViewHostDelegate::RenderViewReady is dispatched
whenever a RenderView is created from RVHI::CreateRenderView (as soon
as its process is ready).  However, if we reused a RenderViewHost
which was previously swapped out for a new navigation, which made the
RenderViewHost active, the RenderViewReady was not dispatched.  One of
the consumers of the corresponding
WebContentsObserver::RenderViewReady method was the SadTabHelper.
This meant that if a tab was showing a sad tab, and a subsequent
navigation reused a RVH bringing it into an active state, the sad tab
was not hidden.  To fix this, this CL dispatches RenderViewReady in
that case.

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

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

[modify] https://crrev.com/61e1fcd02e595f2e882f9e702f69f3363ca9ae6b/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/61e1fcd02e595f2e882f9e702f69f3363ca9ae6b/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/61e1fcd02e595f2e882f9e702f69f3363ca9ae6b/content/browser/renderer_host/render_view_host_impl.h