Related bugs:

Issue 677132 to make this error have a human readable title
 Issue 47450  to deal with the fact that extension option pages can't open in incognito

My suggestion:
AFAIK, the only time an extension can actually block a request is using the (declarative)webRequest API.  BLOCKED_BY_CLIENT makes sense for when the client is blocking a request, so I think we should just replace the single usage in webRequest with a new ERR_BLOCKED_BY_EXTENSION, and update BLOCKED_BY_CLIENT to not mention extensions.

I like this idea, let's do that.

+a couple of net/ OWNERS for their opinions, since this would be adding a new error code.  Additionally, having the concept of extensions in //net is a bit of a layering violation, and not sure if there's any precedence or alternatives.

All new //net error codes need go through UI leads, since they end up surfacing as user-visible.

There's definitely unease with exposing the notion of extensions to //net, which operates in extension-less contexts (whether through WebView or through Cronet), and which violates the layering AIUI (//content doesn't know of/require extensions, AIUI, and //content depends on //net).

From the //net perspective, all requests blocked by the //net embedder are indistinguishable - hence ERR_BLOCKED_BY_CLIENT. Alternative approaches to solving this problem seem to include simply revamping the strings (e.g. accepting that //net doesn't want to know about the reasoning) to not mention extensions, or questioning whether the loader (which the navigation throttle seems to be the new code synthesizing this error) should have better opportunities for integration other than injecting an error code.

My own instinct is to say "Change the error message" (because it's easiest), but it would be good to understand the use case more and see if we can't avoid exposing extensions to //net.

The drawback to simply changing the string is that, if the request was blocked by the webRequest API, "check your extensions" is exactly the right message to display.  I think Nasko did some archaeology and it used to be that BLOCKED_BY_CLIENT was really only used for extension cases, which meant this was correct.

I think it's beneficial to be able to present two different error strings for the cases of something actually being blocked by an extension and something being blocked by chrome for other reasons.  Beyond that, I don't have a strong preference.  So if that's done by somehow adding extra data in addition to the error code and having both cases still represented by BLOCKED_BY_CLIENT, that's fine with me (but Nasko and others would know better how easily that might fit into the content/ stack).

+ rachelis@ and edwardjung@ who last looked at network errors

What do you recommend for funneling new errors? Apologies if I'm misapplying your work here/there are new contacts. I believe this overlaps with interstitial error messaging. Looks like there was some comment discussion on the audit deck about the details section for this specific error:

https://docs.google.com/presentation/d/18bmk0A1BS3GEo6iRXophmpquUzrpMgA8EgFTo8SS__I/edit#slide=id.g59ad1b5ff_0_140

Thanks Rolfe! We're happy to handle them. Is this a new error, or feedback / revision on an existing one?

rachelis: There's a question about whether to rephrase an existing error or introduce a new error with new phrasing

My feeling is to introduce a new error extensions specific type. The current one has a specific action that a user can take which is good. 

If we make it generic then we'll have to suggest multiple things, some which might not work to cover all possible cases. Unless of course as part of surfacing this error, it was possible to know whether it was caused by an extension versus general browsing and show only the most pertinent suggestion.

Devlin, are you the right person to take this?

@13 - maybe, once we know what we want to do. :)  It'll probably be one of [me, nasko, rsleevi], but we need to first decide if we introduce a new code, try to somehow differentiate errors from a single code, rephrase the string, etc.

Nasko, Ryan - is there any easy way we could differentiate with a single error code?  That would allow us to improve the messaging while not introducing a new code or violating layering concepts.

@15 - I'm not sure I grok what you're asking. From the //net side, our only API for surfacing those details is the error code - and error codes don't get to stash extra data on, they become new error codes. If you want to stash extra data onto the URLRequest, that may be possible for extensions (so that extensions can force associate this URLRequest with an indicator that webRequest is blocking it, and then //chrome, which can depend on //extensions, can extract this association), but we can't really do it at the error code level.

I'm not a good one to implement; for the "Using URLRequest like a SupportsUserData" thing, that's something davidben@, eroman@, mmenke@ would know more about. It looks like //content does these sorts of tricks ( c.f. https://cs.chromium.org/chromium/src/content/browser/loader/resource_request_info_impl.cc?rcl=769f9a4d6edea0cf066def627d919a65f678fa18&l=317 and https://cs.chromium.org/chromium/src/content/common/net/url_request_user_data.h?rcl=769f9a4d6edea0cf066def627d919a65f678fa18&l=12 so I suspect it is)

It's certainly possible to stash more data using UserData, but then we'd still need to pass the new non-net error data down to the renderer (And would other c/b/r consumers care about it)?  Handle the new type of data in the error page logic, etc.

 Issue 793658  has been merged into this issue.

 Issue 823330  has been merged into this issue.