Unable to reproduce the issue on the reported chrome version # stable 
61.0.3163.100, on the latest canary 63.0.3235.0 on Windows 10, 
Ubuntu 14.04 and Mac 10.12.6, by the following steps mentioned.
1.Added a chrome extension which blocks specified pages
2.Tried opening one of the blocked pages
3.Refreshed the page which has a message stating "this page has been blocked"
Found the message being displayed usually even after refreshing. The blocker we used https://chrome.google.com/webstore/detail/simple-blocker/akfbkbiialncppkngofjpglbbobjoeoe?utm_source=chrome-ntp-icon

Attaching the screencast of the same.
@Reporter: Could you please let us know whether we have missed anything in reproducing the issue. And let us know the extension yopu are using.

Thanks!

Deleted: 772771.mp4 2.9 MB

	772771.mp4 2.9 MB View Download

It cannot be reproduced using SimpleBlocker, because it uses it's own blocked page message. The problem seems to appear only with native Chrome's message. I'm posting here screen recording of my extensions, so you can take a look at it.

Deleted: 1.mp4 622 KB

	1.mp4 622 KB View Download

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

@ hakerh403: Thanks for the update, can you please help us with the sample extension if possible. This will help us to triage the issue better.

Thanks.!

@ranjitkan: The code of the extension is very short and can be seen on the video I've posted. Anyway, I'm uploading an attachment here containing whole extension.

Deleted: 1.zip 1.5 KB

1.zip 1.5 KB Download

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Tested on latest Chrome Stable #61.0.3163.100, Canary # 63.0.3239.1 on Windows 10 and Mac 10.12.6 and able to reproduce the issue.

Using the manual bisect providing the bisect results,
Good build: 61.0.3163.58 (488528)
Bad build: 61.0.3163.59 (488528)

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/61.0.3163.58..61.0.3163.59?pretty=fuller&n=10000

Suspecting Change:
https://chromium.googlesource.com/chromium/src/+/638efb21f953c250cc43767eb6f16eacc63eb8b2

From the CL above, assigning the issue to the owner concerned.

@rsleevi:  Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned.

Note: 
1. Issue is not reproduced on Ubuntu 14.04.
2. Provided manual bisect as per revision bisect provided all good builds.

Thanks.

Assigning back; definitely not related to my changes.

Suspecting Change:
https://chromium.googlesource.com/chromium/src/+/7cd99293fcd890cdbc9c840074111e26ec6eeb7e 

From the CL above, assigning the issue to the owner concerned.

@msarda:  Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned.

Thanks!

My change is related to the chrome.identity extension API which is not used by the example extension (it is not present in the manifest file seen at 0:10 secs at comment #4). This looks like a bug in the extensions so I am reassigning to the rdevlin.cronin@chromium.org for triage. 

Another change related to extensions in the changelog is https://chromium-review.googlesource.com/c/chromium/src/+/626724 . I am CC-ing the author (jdufault@chromium.org).

+a couple navigation experts.  creis@, alexmos@, ideas?  Naively, I'd wonder if when we cancel the navigation for the extension, we then commit an error page (or about:blank) instead.  Then, when refreshing the page, we try to recommit e.g. about:blank, and it doesn't hit the extension.  But that's a total shot in the dark.  One thing I do find a bit disconcerting is the URL shown in the omnibox on page refresh stays at github.com in the video in #4 - it seems like either we should be at a different origin or should show the blocked screen.

The CL in comment #12 is a cherry-pick; the actual CL is https://chromium-review.googlesource.com/c/chromium/src/+/603167. Changing cc to tbarzic@

I'm guessing this is because of this code that nasko@ added in r474535 [1]:

  // When a navigation in the main frame is blocked, it will display an error
  // page. To avoid loading the blocked URL on back/forward navigations,
  // do not store it in the FrameNavigationEntry's URL or PageState. Instead,
  // make it visible to the user as the virtual URL. Store a safe URL
  // (about:blank) as the one to load if the entry is revisited.
  // TODO(nasko): Consider supporting similar behavior for subframe
  // navigations, including AUTO_SUBFRAME.
  if (!rfh->GetParent() &&
      IsBlockedNavigation(navigation_handle->GetNetErrorCode())) {
    DCHECK(params.url_is_unreachable);
    active_entry->SetURL(GURL(url::kAboutBlankURL));
    active_entry->SetVirtualURL(params.url);
    if (frame_entry) {
      frame_entry->SetPageState(
          PageState::CreateFromURL(active_entry->GetURL()));
    }
  }

Basically, the motivation was that for blocked navigations, reloads of the error page should *not* attempt to reload the original request for security reasons (see  issue 723796 ).  It seems nasko@'s fix will cause these reloads to go to about:blank instead, as that's what we stamp as the NavigationEntry's URL.  I agree that this behavior is a bit weird, and that it might make more sense if we just reloaded and kept showing the actual error page, but I don't think we have an easy way of doing that today without requesting the original resource again.  However, lukasza@ is working on making error pages commit with the chrome-error:// URL instead of the URL that failed to load, which should make this possible.

[1] https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_controller_impl.cc?l=953&rcl=3813cdc5d461f3f45465f8e63d1dbc9f1364ed4c

from #16, it sounds like this might fall into lukasza@'s work, so assigning to him for now.  Feel free to reassign as appropriate. :)

I have a CL removing the code in comment 15, so I'll take ownership of this.

Should be fixed by r511942.

Just verified the fix in 64.0.3251.0 using the extension in comment 7 and reloading a blocked page.