I can't tell the intent of this API from the documentation at https://developer.chrome.com/extensions/proxy#event-onProxyError. However the current implementation looks to have some problems .

The current implementation notifies listeners of two broad classes of errors:
   (1) If any URLRequest fails with an error that could be attributed to a proxy
   (2) If using a PAC script, and that PAC script threw an error


The first concern is around the ambiguity of what a proxy error means in (1). The current implementation (ChromeExtensionsNetworkDelegateImpl::ForwardProxyErrors) implies that we are concern with URLRequest errors and not proxy errors. The distinction is that in servicing a URLRequest, we may attempt connections through a *series* of proxies. The URLRequest only fails and reports this error if the the entire fallback chain could not be satisfied. So one interpretation of chrome.proxy.onProxyError is that it would fire if any of the possible proxies failed.

The other trickiness is defining what a "proxy error" means. There are a mix of connectivity level errors, as well as protocol level errors, and a lack of consensus on what "errors" actually mean. For instance a proxy can be reachable, however it fails to service the request. Is that a proxy error worthy of being reported? Chrome has butted heads on these sorts of issues for years, see  crbug.com/680837 .

The current implementation of ForwardProxyErrors looks like this:

void ChromeExtensionsNetworkDelegateImpl::ForwardProxyErrors(
    net::URLRequest* request,
    int net_error) {
  if (net_error != net::OK) {
    switch (net_error) {
      case net::ERR_PROXY_AUTH_UNSUPPORTED:
      case net::ERR_PROXY_CONNECTION_FAILED:
      case net::ERR_TUNNEL_CONNECTION_FAILED:
        extensions::ProxyEventRouter::GetInstance()->OnProxyError(
            event_router_.get(), profile_, net_error);
    }
  }
}

It includes ERR_TUNNEL_CONNECTION_FAILED, which is a different policy from how Chrome (now) considers proxy errors for fallback ( Issue 680837 ). It also doesn't check for ERR_MANDATORY_PROXY_CONFIGURATION_FAILED. And given that it is checking some protocol-specific errors, it is unclear whether the intent is to check for all of them (say, ERR_PROXY_CERTIFICATE_INVALID, ERR_SOCKS_CONNECTION_FAILED).

The implementation for notifying PAC script errors is mostly fine, except it doesn't properly handle the ERR_MANDATORY_PROXY_CONFIGURATION_FAILED. (The callback includes a "fatal" boolean, which the PAC error path unconditionally sets to "false").


It would be good to better document what the API aims to do, and how users are currently using it.

I am skeptical of the need for consumers to do this given all the ambiguity in classifying errors, so it would be great if we could even deprecated/remove this and give them a better way to satisfy their use-case.