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

commit 5d3c7566f8d3004d7860850d770abd65a61d5dbd
Author: Max Morin <maxmorin@chromium.org>
Date: Fri Jan 04 12:15:16 2019

Disable flaky MimeHandlerViewCrossProcessTest.NavigationRaceFromEmbedder

Tbr: fsamuel
Bug: 914587, 918784
Change-Id: I7d6dbde2c72048d493c1f2e5ca14bfe803f2b91c
Reviewed-on: https://chromium-review.googlesource.com/c/1396022
Reviewed-by: Max Morin <maxmorin@chromium.org>
Commit-Queue: Max Morin <maxmorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#619918}
[modify] https://crrev.com/5d3c7566f8d3004d7860850d770abd65a61d5dbd/extensions/browser/guest_view/mime_handler_view/mime_handler_view_browsertest.cc

+ekaramad, alexmos

I'm not entirely sure what to do with this. I made a blink change that caused about:blank navigations to commit asynchronously (except when the about:blank is the frame's first navigation). It's unclear to me why this timing change would cause the flaky DCHECK failure being seen over here.

It looks like this is crashing on a DCHECK because WebContentsImpl::CanAttachToOuterContentsFrame() is unexpectedly false. This because the FrameTreeNode in question is still reporting as loading (presumably because a previously synchronous about:blank navigation is now async?). This DCHECK was added very recently (in https://chromium-review.googlesource.com/c/chromium/src/+/1298354), so cc:ing the author/reviewing for guidance.

The current logic for attaching a MimeHandlerViewGuest WebContents to its outer WebContents invovles navigations to about:blank. This is changing soon as I am reworking the logic. So fixing this might not be worthwhile. I recommend disabling the test (I could do it tomorrow) and then you could assign this bug to me. I will enable it again when the new logic lands.