There has only been 2 occurrences of this kill since 53.0.2761.2, when the other fixes for issue 612713 have landed.  (a7b35b6600000000/cb8d5b6600000000 is one case on Windows, and e93a823a00000000 was me testing these repro steps on the Mac.)

With half of the Canary/Dev population on the new navigation path and exposed to this bug, it suggests that it's very uncommon in practice. 

https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20product.version%3E%2753.0.2761.0%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer%20kill%5D%20content%3A%3ANavigationControllerImpl%3A%3AIsURLInPageNavigation%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

I'll remove the blocking label and disable the test for the moment, and we can come back and fix it after switching to the new navigation path.

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

commit 128faaf6f959fe4ab60578d3c6db8480fc932d49
Author: creis <creis@chromium.org>
Date: Fri Jun 24 20:15:04 2016

Disable test for rare in-page navigation kill in new navigation logic.

This case is almost never hit in practice, so it should be safe to
switch to the new navigation path before fixing it.

BUG=618100
TEST=No product behavior change.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/128faaf6f959fe4ab60578d3c6db8480fc932d49/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/128faaf6f959fe4ab60578d3c6db8480fc932d49/testing/buildbot/filters/isolate-extensions.content_browsertests.filter
[modify] https://crrev.com/128faaf6f959fe4ab60578d3c6db8480fc932d49/testing/buildbot/filters/site-per-process.content_browsertests.filter

Note: This is not resulting in a NC_IN_PAGE_NAVIGATION renderer kill anymore.  However, we do get a renderer crash in NavigationControllerBrowserTest's BackTwiceToIframeWithContent test in debug mode if running in --site-per-process, since we hit the following NOTREACHED in RenderFrameImpl::NavigateInternal:

        if (history_load_type == blink::WebHistorySameDocumentLoad) {
          // If this is marked as a same document load but we haven't committed
          // anything, treat it as a new load.  The browser shouldn't let this
          // happen.
          if (current_history_item_.isNull()) {
            history_load_type = blink::WebHistoryDifferentDocumentLoad;
            NOTREACHED();

That happens in step 6 of the repro steps.  The browser process classifies it as a SameDocument navigation when it should be a DifferentDocument navigation.  We're actually going from the cross-site page to the initial data URL in the subframe in step 6, but the last committed NavigationEntry says we're already on the initial data URL in that frame.  (We just never told the frame to navigate there in FindFramesToNavigate due to the fix for  issue 598043 .)

We should really be comparing against the actual last committed FrameNavigationEntry for the frame (perhaps stored on the RFH?), rather than the FrameNavigationEntry in the last committed NavigationEntry.  This will matter in the case of slow back/forward subframe navigations as well, when we're actually headed to the FNE in the NavEntry but haven't gotten there yet.

Fixing this will let us re-enable the BackTwiceToIframeWithContent test.

You started fixing this bug over two years ago. Are you still working on it? You can update the status to "archived", "wontfix", or "closed". You can remove yourself as owner and change status to "untriaged", but if this is still a real bug, please do not sit on it.