I think this is a //content layer thing. I know error pages have this URL, but it should be hidden? Adding navigation labels.

Yes, that's used behind the scenes when we show an error page.  It shouldn't end up as a visible URL when reloading the page, so it's definitely a bug.  Thanks for the report.

I can't seem to repro it by shutting down a server, getting to the error page, starting the server, and reloading (either via the reload button next to the address bar or the blue reload button on the page).  Tried testing on both 51.0.2704.106 on Mac and 54.0.2804.0 on Linux.  Also not sure how we would get into that state, so being able to repro it would be useful.

Are you able to find any more specific steps that lead to the bug?

This happened again, the steps were like:

1. I had site opened like http://vagrant.local.uk.example.com/
2. My hosts have this line:

192.168.88.89 vagrant.local.uk.example.com xhprof.drupalvm.dev

3. I've restarted computer (Chrome was forced to quit).
4. After restart, the Chrome windows was re-opened.
5. I've restored my tabs, but the above link showed that the page can't be opened (because VM wasn't ready).
6. I've restored my VM (vagrant up).
7. I've refreshed above link, it went to: data:text/html,chromewebdata

The page is showing icon which says: Your connection to this site is not private.
And also showing the previous history of tabs (which previously I didn't have).

It also shows in history (but maybe, because I've back and forward again).

Deleted: Screen Shot 2016-08-05 at 22.53.53.png 93.5 KB

	Screen Shot 2016-08-05 at 22.53.53.png 93.5 KB View Download

Deleted: Screen Shot 2016-08-05 at 22.55.13.png 24.0 KB

	Screen Shot 2016-08-05 at 22.55.13.png 24.0 KB View Download

Similar:  bug #633561 

Thank you for providing more feedback. Adding requester "creis@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning to get out of untriaged queue. creis@ has the ball.

Thanks for the extra details in comment 5.  I'm traveling and won't be able to look closely until next week.  CC'ing a few people who might know about error pages in case they have ideas in the meantime.

That's the URL that's used for the error page, but my understanding is that we try to keep it out of the history list for exactly this reason (i.e. that we want reloads to reload the main page).  I presume there's something about the repro steps that interacts badly with how we're trying to avoid having the error page actually show up in the history list, but I'm not offhand guessing what.

@creis: You probably know this, but the relevant code is in src/chrome/renderer/net/, src/components/error_page/renderer/, and that code is hooked from RenderFrameImpl via various calls to GetNavigationErrorStrings.  Not sure of where the history links are.

The only place where components/error_page does a navigation is when it calls loadHTMLString on fetching navigation corrections.  This is the same thing RenderFrameImpl::LoadNavigationErrorPage does in the more standard error page path.  I believe those are the only two places where we actually load a doc using that URL, so presumably this is a change in how loadHTMLString is behaving.  I know nothing about the innter workings of that method.  Error pages have been loaded using it since before I started working on Chrome.

Happened again at random (this time not related to VM site). I had some internet shortage where all the pages weren't loading properly, just loading for few minutes. Then the loaded page after retry became chromewebdata. I couldn't go back what was the previous page (which I've lost), but the favicon was still there.

Deleted: Screen Shot 2016-10-10 at 11.28.40.png 27.9 KB

	Screen Shot 2016-10-10 at 11.28.40.png 27.9 KB View Download

Alex, do you have any ideas how this might happen?  I know you were looking at error pages recently, so maybe you've got a better sense than I do.  (I'm fairly unfamiliar with how it works.)

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919