Yes, it looks like my change to NavigationControllerImpl::RendererDidNavigateToNewPage might have affected this.  Something about the virtual URLs must not be right.

There are some confusing aspects to this, though:

1) It doesn't seem to affect the old settings page.  I was only able to repro with enable-md-settings on about:flags.
2) It's not due to |update_virtual_url| or even the RewriteURLIfNecessary call in RendererDidNavigateToNewPage.  I've copied those from the last case (which is what we did before my CL) and the bug still happens.
3) The bug goes away if I remove the whole in-page casefrom r407832.

Maybe there's some problematic state on the last committed NavEntry that we're cloning?

dbeam@, do you have any ideas what the new Material Design version is doing differently than the old settings page here?  Does it use virtual URLs differently?

dbeam@: I'm seeing some other possible bugs with the new Material Design version here, which makes it hard to tell how to fix this.

After reverting my CL locally, I'm still seeing the following bug:
1) Visit chrome://help (in Material Design mode)
2) In the left menu, choose "People."  The omnibox changes to chrome://settings/people.
3) In the left menu, choose "About Chromium."  The omnibox changes to chrome://settings/help.

In step 3, shouldn't that be chrome://help?  It seems strange that it would be two different URLs depending on how you get to it.

What is the desired behavior here?

new settings doesn't live in a frame and uses history.pushState():
https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/settings_page/settings_router.js?type=cs&q=pushState+file:%5Esrc/chrome/browser/resources/settings/&sq=package:chromium&l=69

old options uses either pushState or replaceState and tries to keep 2 frames in sync (the content frame and the outer frame that shows the user-visible URL):
https://cs.chromium.org/chromium/src/chrome/browser/resources/uber/uber_page_manager_observer.js?q=pagemanager+pushstate&sq=package:chromium&l=50&dr=C

+tommycli@ as he's been doing a lot for routing in new settings lately

oh, I'm reading the bug more now: I honestly don't care that much as to whether chrome://settings/help or chrome://help is shown as long as:

1) typing both of those URLs into the omnibox gets you the in-page contents
2) clicking on the "About Chrome" menu item in md-settings shows the same URL every time (regardless of what it is)

does that make sense?

I don't understand what you mean in (2).  Before my CL landed, if you start from chrome://help and click "About Chrome", you stay on chrome://help.  If you start from chrome://settings and click "About Chrome", you go to chrome://settings/help.  That means the menu item does two different things depending on where you start from.

What behavior do you expect there?

creis@: ah, I'd expect starting from chrome://settings and clicking on "About Chrome" to go to the same URL as going to the help page directly.

I don't really care whether that URL is chrome://help or chrome://settings/help.

This issue is still seen on chrome latest Dev M55-55.0.2880.0. Observing Ominibox url does not changes after selecting any tab from side menu.

Removing milestone label M-54 and adding M-55.

 Issue 668448  has been merged into this issue.