Tested the issue on various Chrome versions and below are the observations,
Not seeing any blank page when navigated to chrome://blank, observing the following text --

(i) From Chrome M30# 30.0.1599.0 to M49# 49.0.2621.0, the text displayed is "This webpage is not available".
(ii) From Chrome M49# 49.0.2622.0 to M51# 51.0.2670.0, the text displayed is "This site can’t be reached".

Please let me know if any more information is required. Removing Needs Bisect label as of now as this is a Non-Regression Issue.
Thank You.

Can you please bisect this one step further back? In M48 we show a blank page, I'd like to know when that changed to showing "This site can't be reached".

Verified the issue and found the issue to be broken in M50, below are the steps followed,

M50# 50.0.2653.0
(i) Navigated to chrome://blank and observed the text "This site can’t be reached."
(ii) Navigated to about://blank and observed a blank page.

M50# 50.0.2654.0
(i) Navigated to chrome://blank and observed the text "This site can’t be reached."
(ii) Navigated to about://blank and observed the text "This site can’t be reached."

Providing the bisect information accordingly,

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/cf186a3887a562701a0f52b216a4b05ac136d0f0..6a3499af436126e87e24365d3a246e9aff928e37

@pdr -- I could not find any possible suspect from the CL provided. Could you please look into the issue and update.
Removing the appropriate labels.
Thank You.

I think this may be https://crrev.com/f3f7914b87f6482c07360f9748e73c3cacf33fa2

Tagging as RBS so will be prioritized in our triaging bucket, please feel free to change if needed.

I tried reverting that change (my change) locally.  The bug still appears.  (chrome://blank shows "This site can’t be reached.")

Assigning back to pdr@

@mpearson, can you please bisect around the regression range to find the real culprit? This is not really an area I'm familiar with. I don't mean to pick on you, your change just had tests involving "about://" urls which is the only thing that seemed even close to related.

This is not an area I'm familiar with either.

That said, if you want me to bisect, I'm willing.  My calendar for the rest of this week is full though; it'll have to wait until Monday.

Both chrome://blank and about://blank still shows "This site can’t be reached" on latest canary M 51.0.2677.0.

pdr@, there are separate possible destinations here.

1. chrome://blank

This is a longstanding issue as mentioned in comment #1.  chrome://blank has displayed an error page in one form or another since at least M-30.
creis@ might know how to fix this.  If this is fixed, the other issue becomes moot.

2.  about:blank

This works on the current top of tree and as near as I can tell has always worked.

3.  about://blank

You're right, this is my change.  My change causes about://blank, when typed in the omnibox, to navigate to chrome://blank/ instead, which has the aforementioned error page.

Note that this is only broken when typed into the omnibox.  If you follow a link to about://blank/, it works.  Furthermore, :// isn't supposed to be used with the about scheme.  Only : is.  Given these two constraints, I'm revising the severity and removing the releaseblock label for this.

I can fix item #3 in comment 11.  I'm hoping creis@ know off the top of his head how to fix item #1.

Actually, I'll just assign this to creis@ as part of item #1.

Item #3 is not fixable in a reasonable way.  The only way to fix item #3 (which is what I intended to do) is put in a hack in the omnibox suggestion code to either
- redirect suggestions for chrome://blank to about:blank.  This seems like a ugly hack to get around the primary issue.
or
- not offer any builtin suggestions (e.g., about://histograms) for about://.  Ugh.  People use these.

#1 is working as intended.  We intentionally don't treat chrome://blank as about:blank.  Instead, it's an invalid URL, similar to chrome://asdf.

In general, we rewrite many about: URLs into chrome:// URLs (e.g., about:settings into chrome://settings), but we don't rewrite in the other direction.  These schemes aren't equivalent-- chrome:// URLs are privileged and can navigate to other chrome:// URLs (like Settings or Downloads), which most pages (including about:blank) aren't allowed to do.  We've seen that sort of navigation between chrome:// URLs frequently in sandbox escapes, so we try to limit the attack surface and opportunities for confusion.

Since mpearson@ says #3 is also not easily fixable, I'll go ahead and close this.  (pdr@, let me know if there's a specific reason you needed this, but there's strong security incentive not to support it.)