Please find attached a net-export created with Chromium Version 61.0.3133.0 (Entwickler-Build) (64-Bit)

Deleted: chrome-net-export-log.json 226 KB

chrome-net-export-log.json 226 KB View Download

cc'ing eroman@ and mmenke@ for further triage.

That log doesn't contain enough information, unfortunately.  You need to start logging before you start loading a page that is slow.  It looks like logging started while a page was hung, so we can't see what the last interesting event that didn't hang was.

Oops, sorry, I missed the important request - so it looks like the issue is DNS lookups for "Thomass-MacBook-Pro.local" are taking five seconds.  It looks to me like this is a request issued by the PAC script, as opposed to a DNS request used for fetching the PAC script.  So you're running a PAC script that always wants to look up this domain, and the domain lookup always fails, but your DNS server takes us 5 seconds to tell us it failed.

This happens on every single request.  Which makes things basically unusable.  I'd suggest either fixing your PAC script not to do that lookup, or figure out why your DNS resolver is always timing out.  Not sure there's much we can do on our side (We could cache negative DNS results, but then if you have a flaky network, we could break a site, which also seems bad).

"Thomass-MacBook-Pro.local" is the name of my Mac Book. Of cause it does not exist in the DNS. Every Apple Computer using Mac OS get's such a name during setup.
This name is not part of the PAC.
Why should the PAC lookup names? Maybe that's the issue? The PAC should just compare domains but it should not lookup domains.
Also it can not lookup for example google.com as the internel DNS server will not provide information about external domains. Only the proxy needs to do DNS lookups.
The same proxy pac works fine in Firefox, Safari and IE.

I have reduced the PAC, see below, and the issue is with myIpAddress(). In my point of view it does not make sense to resolve the local name, as this is usualy set to something useless and no DNS server will resolve it.

If I try to resolve I get the following result immediately:
$ host Thomass-MacBook-Pro.local
Host Thomass-MacBook-Pro.local not found: 3(NXDOMAIN)

If you use the following PAC and try to open something from localhost, you will see the same issue, without any proxy or external server involved.

function FindProxyForURL(url, host) {

  var myIP = myIpAddress();

  return "DIRECT";
  
}

[th.scheller@gmail.com]:  Sorry for the slow response.  Could you provide a new log from about:net-internals showing the issue?  (about:net-export is replacing about:net-internals, but it doesn't have quite as much hooked up yet).

Oops, sorry, missed comment 6, new log not needed.  myIpAddress just gets the local hostname and does a DNS lookup using it.  Seems very weird that a mthod to get the local hostname does not return something that can be resolved.

Sounds like the issue is identified in comment #6.

We probably need to do re-write myIpAddress() (and myIpAddressEx()) for all platforms (except ChromeOS), as resolving the hostname as a means of obtaining it is unreliable.

I guess we'd have to enumerate all network interfaces, and try to pick the "best" one?  Or is there another way to get the local IP address?

There are a variety of hacky approaches, each with their own problems.

I will open a bug with some extra info and merge the related bugs in.