Here are repro steps for repro'ing with a normal net error. The tl;dr is that anytime you reload an error page and get a non-error page after reloading, you end up with a new navigation entry instead of replacing the entry for the error page.

1.) Modify /etc/hosts to simulate a network error on example.com, for example map example.com to 127.0.0.1 (assuming you don't have anything listening on 127.0.0.1:80).
2.) Navigate to example.com, observe a net error page.
3.) Undo your /etc/hosts modification and refresh example.com to get the actual example.com to load.
4.) Look in your navigation history and observe that there is a navigation entry for the error page from step #2; that is, refreshing in step #3 created a new navigation entry, whereas ideally it should replace the current entry.

As Carlos mentioned, the refresh seems to fall into this case in ClassifyNavigation: https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_controller_impl.cc?q=ClassifyNavigation&sq=package:chromium&l=1120, where we classify it as NAVIGATION_TYPE_NEW_PAGE because the site instances before and after reload are different.

One possibility we were discussing is if we should return EXISTING_PAGE in the case where GetLastCommittedEntry() is an error page, but we couldn't really convince ourselves if that was correct or not, or might have other unintended effects.

Thanks for the bug report! I confirmed the repro steps in comment 2 do work for me. One small note is that one can avoid making changes to /etc/hosts and can just use an extension like Offline Mode (https://chrome.google.com/webstore/detail/offline-mode/jmfdoanbhalcgkfhpedjnljaoadhlmeg) to cause an error page to be rendered (while in offline mode) and later on reload to succeed (when in online mode).

A detail I noticed is that if the reload is done through the browser top level UI button, the issue does reproduce. However if the reload is initiated through the HTML button on the error page itself, it does not add a new entry. I will investigate further and see what the difference in the underlying behavior is.

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

commit d515cab0d9f6913d8a139dc0484a451f6d23524a
Author: Nasko Oskov <nasko@chromium.org>
Date: Wed May 09 15:34:20 2018

Disable error page isolation temporarily.

The isolation of error pages has caused at least one functional regression
described  https://crbug.com/840485  and causes various renderer process
terminations. This CL disables the isolation functionality so these can
be investigated and fixed before re-enabling.

Bug:  838161 ,  840485 , 840794, 840701
Change-Id: Id25937f6f400578c7c8bf315551b3878b4a4937c
Reviewed-on: https://chromium-review.googlesource.com/1050431
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557191}
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/chrome/browser/chrome_security_exploit_browsertest.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/browser/frame_host/navigation_handle_impl_browsertest.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/public/browser/content_browser_client.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/public/browser/site_isolation_policy.cc
[modify] https://crrev.com/d515cab0d9f6913d8a139dc0484a451f6d23524a/content/public/browser/site_isolation_policy.h

Just a quick update on this bug - it is actually not restricted to error page isolation, it was just easily discovered this way. In general, we add a new session history entry every time we perform browser-initiated reload of a document which changes its SiteInstance. There is already an existing test for this - AppApiTest.ReloadIntoAppProcess, however it does not check whether we add more session history entries, just checks process separation. I will be adding checks to this test to ensure we don't regress it again in the future.

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

commit aee2f86ac16f51525a7058c5339a8dcad3a38bc7
Author: Nasko Oskov <nasko@chromium.org>
Date: Fri Jun 15 00:05:52 2018

Fix session history navigations and reloads which change SiteInstance.

Reloading an URL usually does not change its SiteInstance, however there
are a couple of exceptions - hosted apps and recently isolation of error
pages. In both of these cases, a commit for a specific URL can happen
in SiteInstance A and a subsequent reload results in a change to
SiteInstance B. With error page isolation, this can happen easily due
to timeout or some other transient network error on the initial navigation
to the URL, which ends up in an error page process. A later successful
reload then results in a different SiteInstance for the same URL.

Session history navigations are similar in behavior. When navigating
back/forward, the navigation can be redirected cross-site, resulting
in a SiteInstance change.

This CL changes ClassifyNavigation to account for these and classifies
them as NEW_PAGE with replacement. It ensures that when an entry's
SiteInstance changes, which means the security context has changed,
we don't reuse and update the existing entry, but rather we replace it
with a newly constructed one.

The CL adds a specific test for session history navigations that are
redirected and adds session history length checks to the existing test
of reloading a hosted app, which changes SiteInstances.

Bug:  840485 ,  848446 
Change-Id: Iabacc60ce5726d5d919877b6e65e5d2f51dff3e2
Reviewed-on: https://chromium-review.googlesource.com/1086876
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567492}
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/chrome/browser/extensions/app_process_apitest.cc
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/content/browser/frame_host/navigation_controller_impl.cc
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/aee2f86ac16f51525a7058c5339a8dcad3a38bc7/content/browser/frame_host/render_frame_host_manager_browsertest.cc

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

commit 307e8978a2282eb186f3a67d1017b38fb92762f0
Author: Nasko Oskov <nasko@chromium.org>
Date: Fri Jun 15 18:40:23 2018

Add ErrorPageNavigationReload test

This is a browser test for  https://crbug.com/840485 . Actual fix is more
complex and will come later. It is useful to have this test committed
so it can be exercised locally with error page isolation enabled.

Bug:  840485 
Change-Id: I755c55694be191e0a0d569fa64b2093e9deb9da7
Reviewed-on: https://chromium-review.googlesource.com/1086875
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567744}
[modify] https://crrev.com/307e8978a2282eb186f3a67d1017b38fb92762f0/content/browser/frame_host/render_frame_host_manager_browsertest.cc

I think this bug can now be considered fixed, even though error page isolation itself is not yet enabled. A test for this was landed in r567744.