I'm confused, this was reported in Chrome Version: 54, but the bisect is for changes in 49. Did you confirm that this crash (which, granted, is an edge case) goes all the way back that far?

The change you reference only changes an unrelated browser test, not production code.

We should triage this normally.

This crash is reported only in 54.0.2793.1/.0, total 6 instances. This is a month old build. I am closing this issue for now . 

Inhouse team please provide the crash impact details for all reproducible crashes.

More Info
=========
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27MojoWebUIController%3Cmojom%3A%3AOmniboxPageHandler%3E%3A%3ARenderViewCreated%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion

Comment 3: Please do not mark crash bugs with working repro steps as WontFix.  They can be indicative of bigger problems, and having repro steps is extremely valuable.

This crash is happening in MojoWebUIController, which was added by ben@ in r401130.  Looks like render_view_host->GetMainFrame() is returning null in this case, which is a bit strange given that there aren't any OOPIFs.  I suspect it's due to needing a different RFH for view-source, even for same-site URLs.  (I think we use a different BrowsingInstance?)

Alex, can you see if this is expected behavior (in which case MojoWebUIController should handle it) or if we should prevent it from happening?  I'm happy to chat about any view-source strangeness to see if we can clean it up.

I reproed this on a ToT build.  (Unfortunately, my recent RenderView creation fixes didn't help.)  The GetMainFrame() is null because the render_view_host in question appears to be in a swapped out state, with main_frame_routing_id_ set to NONE, is_active_ false, and is_swapped_out_ true.  This is the RVH from the pending RFH for the back navigation to view-source.  I don't yet know whether having a swapped out RVH makes sense here and will need to dig further.

I investigated this some more.  What's happening is:

1. Right-click > View source on chrome://omnibox opens a tab in the same BrowsingInstance and SiteInstance as chrome://omnibox.  This isn't specific to view source: another way to trigger this bug is to do a window.open("chrome://omnibox") from chrome://omnibox to open another chrome://omnibox page.

2. Go to another site in the second tab via omnibox.  Original repro uses chrome://omnibox, but this can be any other site. This keeps around the RVH created in step 1 but makes it swapped out.  The second tab's main frame is swapped out to a proxy in the chrome://omnibox SiteInstance, which is tied to that RVH.  (This is because the first tab is still alive and could try to communicate to second tab.)

3. Go back.  The target is chrome://omnibox, and since there's an existing proxy in that SiteInstance, we try to swap it back in and reuse the swapped out RVH from step 2.  As part of that, in UpdateStateForNavigate, we hit:

    // If a WebUI exists in the pending RenderFrameHost it was just created, as
    // well as the RenderView, and they never interacted. So notify it using
    // RenderViewCreated.
    if (pending_render_frame_host_->web_ui()) {
      pending_render_frame_host_->web_ui()->RenderViewCreated(
          pending_render_frame_host_->render_view_host());
    }

Which hits this code in MojoWebUIController:

  void RenderViewCreated(content::RenderViewHost* render_view_host) override {
    MojoWebUIControllerBase::RenderViewCreated(render_view_host);
    render_view_host->GetMainFrame()->GetInterfaceRegistry()->
        AddInterface<Interface>(
            base::Bind(&MojoWebUIController::BindUIHandler,
                       weak_factory_.GetWeakPtr()));
  }

We crash because there's no main frame for the swapped out RVH.  

Note that the first comment about RenderView being new in UpdateStateForNavigate is wrong -- the RVH is reused in this case, and the code isn't detecting that properly.  RenderViewCreated shouldn't be called on this RVH again -- that already happened as part of step 1 (where it was done from RFHM::Navigate).  It seems we should be detecting RVH reuse and calling RenderViewReused instead (which, conveniently, WebUIImpl already supports).

Interestingly, similar comments and calls to RenderViewCreated appear in five different places in RenderFrameHostManager, so they all should be audited for whether they can handle RVH reuse properly.

Of course, MojoWebUIController::RenderViewCreated could just check whether the RVH is active or not, which would fix this, but it seems wrong to call RenderViewCreated on the same RVH multiple times (and perhaps there's a case where we could end up calling it again on the RVH that's active, in which case I don't know what would happen if we try to add the same mojo interface on the same frame twice).

This bug would apply to all chrome:// pages that use MojoWebUIController, which at the moment seems to be:
chrome://omnibox/
chrome://plugins/
chrome://site-engagement/
chrome://usb-internals/

Looks like the fix for this landed in r432757 but bugdroid didn't post an update.  Should this be marked fixed now (along with issue 664958 and issue 664962)?  (Thanks for the fix!)

This should be fixed.  It doesn't repro with the latest Mac canary that contains r432757.  Not sure what happened to the bugdroid comment.