Chrome Version: 64.0.3263.0
OS: All

What steps will reproduce the problem?
(1) Open a file:// URL (e.g., foo.html).
(2) In the DevTools console, type:
var w = window.open("http://csreis.github.io");
(3) After that loads, go back to the original window and type:
w.location.replace("foo.html");
(Or any other file URL)

What is the expected result?
The navigation should be classified as NAVIGATION_TYPE_NEW_PAGE with replacement.  (Before  issue 596707  was fixed, it was classified as NAVIGATION_TYPE_EXISTING_PAGE, which was ok but not great.)

What happens instead?
The navigation is classified as NAVIGATION_TYPE_SAME_PAGE.  That's definitely not correct. 
 SAME_PAGE is meant for the case where the user hits enter in the address bar.  (We want to remove it in issue 536102.)

I spotted this when diagnosing the repro steps for  issue 781488 , while testing with a file:// URL.

We're apparently treating any same-process client redirect and location.replace cases that go through OpenURL as SAME_PAGE as well, because they line up with the conditions required:
1) did_create_new_entry is false.  (True because it's a replacement case.)
2) Main frame
3) nav_entry_id matches the pending NavigationEntry's ID.  (We get a pending NavigationEntry due to OpenURL, which in this case is because of the non-file:// to file:// navigation.)
4) The SiteInstance matches.

Instead of cloning the pending entry, we just try to update the existing one (which could be quite different-- it's for the web URL).  Looks like we're missing updates to at least:
 - TransitionType
 - OriginalRequestURL
 - IsOverridingUserAgent

I'm not sure there's a significant behavior problem here, but we should fix this.  It's probably sufficient to check whether the pending NavigationEntry !is_renderer_initiated() before classifying as SAME_PAGE.