Manual Regression :
Good build: 54.0.2820.0
Bad build: 54.0.2821.0

Narrow Bisect : 
https://chromium.googlesource.com/chromium/src/+log/f536869d57e5ce2e7a5a4b860dcc1e675432face..5a9a30409316fd19af685b1a88ae21b3e51e71c4?pretty=fuller&n=10000

Suspecting: r410150 or 410155 ? from narrow bisect

@creis : Please help to re-assign if your change is not the cause for this issue.

Note : Issue is also seen on Linux (14.04 LTS) OS.

Deleted: Actual_navigation.mov 4.0 MB

Actual_navigation.mov 4.0 MB Download

Deleted: Expected_navigation.mov 2.7 MB

Expected_navigation.mov 2.7 MB Download

Adding release block label, please undo if not the case.

I can confirm, and it does appear to be due to my r410150.  Interestingly, it doesn't affect middle clicking the back button on normal pages, nor other chrome:// pages like chrome-urls or histograms.  Duplicating the tab and then going back/forward also seems to work.  Wow, even typing "chrome://chrome" instead of clicking "About" in step 1 appears to work.

This seems to be specific to doing a back/forward with a new tab disposition (middle click, ctrl click, etc) on the various Settings pages (Settings, About, Extensions), after a renderer-initiated navigation within the process.  It appears to affect both the default Settings and the Material Design Settings, though.

I've noticed that we do get to the commit in the new tab, but nothing displays after that, and we never seem to get to DidStopLoading.  The new tab is in the same process as the original tab (as expected), and the original tab remains responsive.  I don't see any additional failures in debug builds.

Maybe there's something preventing the resources from loading?  I'll keep looking.

I tracked this down.  We're marking the back navigation as WebHistorySameDocumentLoad because it looks like an in-page navigation compared to the last committed NavigationEntry (which hasn't actually been loaded in the newly created tab).

Blink apparently doesn't support SameDocumentLoads very well when there's no committed page.  This wasn't a problem before switching to the new navigation path because the renderer process's HistoryController wouldn't have marked it as a SameDocumentLoad.  It matters now because the browser process isn't checking whether the renderer process has committed a page yet or not.

This can also occur if the renderer process has crashed and then you go back in-page.  (Amusingly, I found this yesterday and it was independently filed as 637220.  I'll mark it as a dupe of this one.)

Note that these bugs are not specific to the settings page.  They'll happen on any in-page navigation.  More general repro steps:
1) Visit http://csreis.github.io/tests/.
2) Visit http://csreis.github.io/tests/#foo.
3) Ctrl+click back.

Or for the crashed process version:
1) Visit http://csreis.github.io/tests/.
2) Visit http://csreis.github.io/tests/#foo.
3) Kill the renderer process in the task manager.
4) Go back.

 Issue 637220  has been merged into this issue.

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

commit 5413169e62dc4c20d31e1afaea680f943bbe085c
Author: creis <creis@chromium.org>
Date: Fri Aug 12 18:32:25 2016

Don't mark a history navigation as in page in a new renderer process.

Blink won't realize that the page needs to be loaded from scratch and
will stay in-page on the initial blank page.  This became a problem
when moving the in-page determination to the browser process, where
we need to check whether the renderer process has a committed page
or not.

BUG= 635403 
TEST=Ctrl+back in page (see bug comment 4 for repro steps)
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/5413169e62dc4c20d31e1afaea680f943bbe085c/content/browser/frame_host/navigation_controller_impl.cc
[modify] https://crrev.com/5413169e62dc4c20d31e1afaea680f943bbe085c/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/5413169e62dc4c20d31e1afaea680f943bbe085c/content/renderer/render_frame_impl.cc

Should be fixed by r411712.

Retested the above issue on All-OS(Windows, Mac & Ubuntu 14.04) with chrome version '54.0.2830.0' and In-page navigation are getting complete after the middle mouse click on back button.

Hence marking the same as TE-Verified-54.0.2830.0.

Attach is the screen cast for the same.

Thank you!

Deleted: Retest-16Aug.mp4 890 KB

	Retest-16Aug.mp4 890 KB View Download

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

commit bebdfe3164e28e099388534bd89b2af2b28d69b4
Author: nasko <nasko@chromium.org>
Date: Wed Sep 07 21:36:39 2016

Add a NOTREACHED for same document load with no history item.

BUG= 635403 

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

[modify] https://crrev.com/bebdfe3164e28e099388534bd89b2af2b28d69b4/content/renderer/render_frame_impl.cc