Looking at https://uma.googleplex.com/timeline_v2?sid=f059f10336380fcb6e5aa97517cc3e92 I judged that the regression was likely between 57.0.2979.0 and 57.0.2982.0.  I scanned those two releases for CL descriptions that included the string "URL", but none of them struck me as likely to be responsible for this bug.  

Scanning the source for places where ERR_INVALID_URL is returned, I see only three places that strike me as likely to be relevant to main frame loads:

* URLRequest::Redirect, testing the new url's validity

* URLRequestDataJob, testing the job's URL's validity

* URLRequestJobManager, testing the incoming URL's validity.

All of these options strike me as being dependent on the implementation of gurl/ (unchanged in this revision range) and the URL value coming in from the user/web.

Broadening the search out based on dev release information (since that's less noisy) and looking at all //net and //gurl commits between 57.0.2979.0 and 57.0.2984.0 doesn't show anything more.  (This is based on https://uma.googleplex.com/timeline_v2?sid=9b74b25cabe7a50a56ae83ccb68d278d ).

While I agree that this spike is revision correlated and important (by the canary graph above, there's about a 5x increase in the frequency of these errors, though the volume is low enough that there's a lot of noise there), I'm not certain about what the next step is to track it down.  Matt, do you have any thoughts about other things to explore?  

To clarify: did you look at all of //url or just GURL? I would also include platform/weborigin in your search for KURL/SecurityOrigin type stuff.

While it's possible that this is due to a bug or change in behavior in URL handling, it's also possible some change causing us to navigate to invalid URLs more often - could imaging an omnibox change, for instance, auto-completing with bad URLs.

So the search space for this is pretty large.

Thanks, both good suggestions.  

The only change in 2979->2984 in platform/weborigin is https://codereview.chromium.org/2588403002, which doesn't strike me as likely relevant.  

With regard to the possibility of changes causing us to navigate to invalid URLs more often, that I did search all the commit descriptions between 2979.0 and 2982.0 for the string "url" (which is a pretty ham-handed search, but does have the virtue of being across the entire space :-}.)

I wonder if we might find something through RAPPOR logging invalid URLs.  Charles, you have RAPPOR experience--any idea if that's likely to provide anything useful?

Rappor will only give you eTLD+1, and is only really useful if you have tons of samples. I am skeptical it will be useful here.

I also don't see anything interesting in that range. Randy, are you interested in owning this? (I assume not :>) Is there more investigation we should perform or are we willing to close this on the assumption that it's the caller's problem not the net stack's problem? Or something else?

You assume correctly :-J.  I don't think it's reasonable to close the bug even if we think it's due to some consumer; that still makes it a bug in Chrome.

I'm really not sure how to manage issues like this.  The framing I have is something like:
* How can we find root cause/debug it?
* How high a priority is it?  

There's a certain tradeoff between the two; if it's really hard to debug, then it has to be a higher priority for us to keep moving forward on it.

I'm neither certain how high a priority this is nor how to move forward on it.  But I do think it's a real bug (i.e. not zero priority).  Does anyone have any suggestions either how we could move forward on it more easily or how we could refine the priority of the problem?

Navigating to an invalid chrome:// URL triggers INVALID_URL.

It just so happens that chrome://plugins was removed [1] in 57.0.2980.0. I think it is plausible that this explains the entirety of the increase. Does anybody else agree?

[1] https://codereview.chromium.org/2630443002

That sounds like a very plausible explanation, though curious that the rate hasn't gone back down as people stop trying to use it.

It looks like Beta is trending down slowly.

I think M57 Stable is still ramping users up, so I would expect this to continue to rise in the short term.

Canary and dev seem pretty consistent, though.  Maybe check back in a month?

Sounds good. Let me add a NextAction to this issue.

When chrome://plugins/ was killed, someone should have thought to provide a placeholder message that explains why. As this entry point to plugin settings (yes, I'm looking for Flash) is all over the web and those help pages aren't going away anytime soon, getting this is most unhelpful.

"This site can’t be reached

The webpage at chrome://plugins/ might be temporarily down or it may have moved permanently to a new web address.
ERR_INVALID_URL"

+tommycli FYI who made the change. Maybe we should have better error messages for wrong/deprecated chrome:// pages.

Looks like the rate of this error started increasing on stable before it switched over to M57, strangely.  Looks like the rate has still not dropped off.  Anyhow, I'm going to go ahead and WontFix this - it looks like this is accounting for 0.001% to 0.002% of requests, which is not nothing, but probably not worth digging into, unless we get more end user complaints about this.  (The only two I see are  issue 	710733  and  issue 701918  - which are indeed about chrome://plugins).