This is a regression. If we roll back to 50, it works again.

I can confirm this same behavior in our environment, and going back to version 50 does work.  So far the only thing we've been able to do to get version 51 working is to specify the --proxy-server command line option, which isn't really an acceptable workaround.

+eroman who knows a lot about Proxy PAC. 

Investigating if the following crash fix which is to UDP code had an impact on Proxy PAC.

https://codereview.chromium.org/2007773002/

Marking as "Release Block Stable" label for now. Please feel free to remove if think otherwise. Thank you.

@levistevens: Can you try running Chrome with the command line flag:
   --disable-out-of-process-pac

And see if it works again?

Conversely to enable the out-of-process mode pass the flag:
  --v8-pac-mojo-out-of-process


The netlog shows that the out-of-process PAC experiment was enabled:
  OutOfProcessPac:Enabled

Tentatively going to blame that -- Anand can you investigate?

@amistry, this worked for us

@levistevens: Can you try running Chrome with the command line flag:
   --disable-out-of-process-pac

Chrome 51, similar set up in terms of proxy pac

and thank you

I can confirm starting Chrome 51 w/ --disable-out-of-process-pac works correctly with a proxy.

levistevens1978@gmail.com: Is your proxy script supposed to resolve microsoft.com to DIRECT? Because that's what I'm seeing in your log, and the connection failure happens while establishing an SSL connection to the server:
t=   7 [st=   0] +HTTP_STREAM_JOB  [dt=1063]
                  --> alternative_service = "Uninitialized :0"
                  --> original_url = "https://www.microsoft.com/"
                  --> priority = "HIGHEST"
                  --> source_dependency = 2275 (URL_REQUEST)
                  --> url = "https://www.microsoft.com/"
t=   7 [st=   0]   +PROXY_SERVICE  [dt=31]
t=  25 [st=  18]     +HOST_RESOLVER_IMPL_REQUEST  [dt=12]
                      --> address_family = 1
                      --> allow_cached_response = true
                      --> host = "www.microsoft.com:80"
                      --> is_speculative = false
t=  25 [st=  18]        HOST_RESOLVER_IMPL_JOB_ATTACH
                        --> source_dependency = 2279 (HOST_RESOLVER_IMPL_JOB)
t=  37 [st=  30]     -HOST_RESOLVER_IMPL_REQUEST
t=  38 [st=  31]      PROXY_SERVICE_RESOLVED_PROXY_LIST
                      --> pac_string = "DIRECT"
t=  38 [st=  31]   -PROXY_SERVICE
t=  38 [st=  31]   +HOST_RESOLVER_IMPL_REQUEST  [dt=0]
                    --> address_family = 0
                    --> allow_cached_response = true
                    --> host = "www.microsoft.com:443"
                    --> is_speculative = false
t=  38 [st=  31]      HOST_RESOLVER_IMPL_IPV6_REACHABILITY_CHECK
                      --> cached = true
                      --> ipv6_available = false
t=  38 [st=  31]   -HOST_RESOLVER_IMPL_REQUEST
                    --> net_error = -804 (ERR_DNS_CACHE_MISS)
t=  38 [st=  31]   +SOCKET_POOL  [dt=1032]
t=1070 [st=1063]      SOCKET_POOL_BOUND_TO_CONNECT_JOB
                      --> source_dependency = 2281 (CONNECT_JOB)
t=1070 [st=1063]   -SOCKET_POOL
                    --> net_error = -102 (ERR_CONNECTION_REFUSED)
t=1070 [st=1063]    HTTP_STREAM_JOB_BOUND_TO_REQUEST
                    --> source_dependency = 2275 (URL_REQUEST)
t=1070 [st=1063] -HTTP_STREAM_JOB

For anyone else seeing this, can you provide a net-internals trace.

nusbaumc@yahoo.com: When you use the "--proxy-server" command line argument, can you check the task manager and see if "Utility: V8 Proxy Resolver" is running?

nusbaumc@yahoo.com: Ignore my last comment (#14).

I have a few things to try if anyone is able to:
1. Please post your platform/OS version. I want to know if this is windows-only or affect other systems as well.
2. Please enable crash reporting in settings. If you see a failure, go to chrome://crashes and see if there are any recent crashes. If so, please respond with the crash id.
3. Try using the --v8-pac-mojo-in-process flag (sorry, only available on the command line) and see if that works.
4. If you are able to (and only if you've cleared it with the right people), please send me your PAC script. Don't post it to this bug unless it's trivial or you're 100% sure it contains no sensitive information.
5. Could you provide net-internal dumps for BOTH working (either using 50, or with --disable-out-of-process-pac) and non-working states.

A few enterprise customers reported their users cannot access webpages since they updated to Chrome M51. They use Chrome on Windows in proxy networks.

They also informed us that it seems myIpAddress() does not retrieve correct IP, resulting in Chrome trying to go DIRECT without proxy. This is similar to what is reported in  crbug.com/612801 .

I am still waiting for Chrome/OS version info and net-internals logs, but shared customer's PAC file privately: https://drive.google.com/a/google.com/folderview?id=0B3B7SKCSXU4SRHFsSUNFc1VMbGM&usp=sharing

amistry@, I shared customer's PAC filed with you.

Thanks. I think I have enough to repro. myIpAddress() is returning "127.0.0.1" instead of the correct IP address.

 Issue 612801  has been merged into this issue.

Ah, that definitely sounds like the problem!

The out-of-process implementation is going to end up calling gethostname() in the sandboxed utility process. Presumably that is leading to the 127.0.0.1 that then causes the incorrect script execution.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a6cd21dab6a285179b02a05e980091c86545d66

commit 3a6cd21dab6a285179b02a05e980091c86545d66
Author: amistry <amistry@chromium.org>
Date: Fri May 27 08:08:43 2016

Fill in the current host name in the Mojo host resolver service when requesting our own IP address.

The V8 proxy resolver uses GetHostName() as the host in the
implementation of myIpAddress(). However, that may not return the
expected hostname when running inside the sandbox. Instead, use the
request's "is_my_ip_address" field to fill in the correct host name in
the browser before forwarding the resolve request to the DNS resolver.

BUG= 615084 

Review-Url: https://codereview.chromium.org/2011293002
Cr-Commit-Position: refs/heads/master@{#396424}

[modify] https://crrev.com/3a6cd21dab6a285179b02a05e980091c86545d66/net/dns/mojo_host_resolver_impl.cc

A temporary workaround until this fix is merged is to go to chrome://flags, find "Out-of-process V8 Proxy Resolver", and select "Disabled".

Thank you for quick fix! I will share the info with affected customers.

Hi,

We also get this bug too, I work on a Windows domain network, with Windows 7 client machines and version 50 is fine, until you update to version 51.

We use "Automatically Detect Settings", http://wpad/wpad.dat, and Chrome tries to connect to any website DIRECT instead of PROXY.

I can confirm that disabling "Out-of-process V8 Proxy Resolver" works fine, but obviously I cannot do this on 600 machines.

I'm not sure how to debug my PAC script to see if myIpAddress() is resolving to 127.0.0.1 or the actual machine IP address, but if someone can tell me how to give more info, I'm more than happy to help.

Thanks.

@26: You can edit your pac script and add:
alert(myIpAddress());
Then go chrome://net-internals and go to the "events" page. The output should be one of the events when you load a page.

Frankly, I am using Chrome 51.0.2704.63 m (64-bit) for Windows 8.1 and I am able to go to www.microsoft.com without any problem (I get redirected to www.microsoft.com/en-my/). Let me know if you think I can help by providing some log files etc.

Hi,
Same here too,corporate environment using PAC file.
Below as reference the unexpected behaviour when debugging PAC file execution.
In respect of V50, function myIpAddress() throws 127.0.0.1 and myIpAddressEx() response is NULL (rather than showing the real IP)

PAC_JAVASCRIPT_ALERT
Start Time: 2016-05-26 17:32:58.207

t=16682 [st=0]  PAC_JAVASCRIPT_ALERT
                --> message = "PAC Debug Information\n-----------------------------------\nMachine IP: 127.0.0.1\nMachine IP: \nHostname: www.googleapis.com\nHost Resolvable: False\nHostname IP: null\nPlain Hostname: False\nDomain Levels: 2\nURL: https://www.googleapis.com/oauth2/v4/token\nProtocol: HTTPS\n"

A build of chromium with the fix is available at https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/396426/

If anyone that's running into this could download and run that and verify it works, that would be helpful.

Disabling "Out-of-process V8 Proxy Resolver" under chrome://flags temporarily fixed the issue for our machines here on our domain. Thanks.

Waiting for the update that resolves the issue before I change that back to default.

amistry@chromium.org - I've just tried the build of chromium on my corporate network and works fine with WPAD :-D.

Is there a programmatic way to set the "Out-of-process V8 Proxy Resolver" flag?

Also, confirmed that disabling the "Out-of-process V8 Proxy Resolver" flag does resolve the issue.

I can confirm for my customer that initial testing of the build of chromium mentioned in comment 30 is working in their environment with automatic proxy detection enabled.

Disabling "Out-of-Process V8 Proxy Resolver" works. Microsoft.com is not supposed to be routed directly, that is why it gets rejected by our firewall.

Is there a way to set this value through the Registry key so that we can push a fix out?

amistry@, as per c#30, do we have a fix?

@amistry: Can you roll back the experiment on M51?

Update: working on a rollback of the fieldtrial.
Hopefully this will be resolved in a few hours.

Restarting Chrome now should pick up the fix.

Please let me know if this works/doesn't work for you.

Do we need a merge here for M51 Or rollback of the fieldtrial is sufficient?

Maybe I'm being a little naive, but how in the world can a Chrome installation "pick up the fix" when it can no longer reach the Internet?

[Automated comment] Less than a week to go before stable on M51, we might already have a stable candidate build. Manual review required.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

[Automated comment] Less than a week to go before stable on M51, we might already have a stable candidate build. Manual review required.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a89910068adf8652d83d05b0c3f47d124b752b21

commit a89910068adf8652d83d05b0c3f47d124b752b21
Author: Anand K. Mistry <amistry@chromium.org>
Date: Mon May 30 01:09:17 2016

Fill in the current host name in the Mojo host resolver service when requesting our own IP address.

The V8 proxy resolver uses GetHostName() as the host in the
implementation of myIpAddress(). However, that may not return the
expected hostname when running inside the sandbox. Instead, use the
request's "is_my_ip_address" field to fill in the correct host name in
the browser before forwarding the resolve request to the DNS resolver.

BUG= 615084 

Review-Url: https://codereview.chromium.org/2011293002
Cr-Commit-Position: refs/heads/master@{#396424}
(cherry picked from commit 3a6cd21dab6a285179b02a05e980091c86545d66)

Review URL: https://codereview.chromium.org/2024553002 .

Cr-Commit-Position: refs/branch-heads/2743@{#121}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/a89910068adf8652d83d05b0c3f47d124b752b21/net/dns/mojo_host_resolver_impl.cc

Before we approve merge to M51, Could you please confirm whether this change is baked/verified in Canary and safe to merge?

This change is in the current canary (53.0.2751.0) and I have verified the fix on Windows 10.

Approving merge to M51 branch 2704 based on comment #50. Please do make sure that it is a safe merge to M51 (fix works fine and no regression). Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ac93ed2a58541d5bcc6f00497fdc37edef9e42bb

commit ac93ed2a58541d5bcc6f00497fdc37edef9e42bb
Author: Anand K. Mistry <amistry@chromium.org>
Date: Mon May 30 07:23:54 2016

Fill in the current host name in the Mojo host resolver service when requesting our own IP address.

The V8 proxy resolver uses GetHostName() as the host in the
implementation of myIpAddress(). However, that may not return the
expected hostname when running inside the sandbox. Instead, use the
request's "is_my_ip_address" field to fill in the correct host name in
the browser before forwarding the resolve request to the DNS resolver.

BUG= 615084 

Review-Url: https://codereview.chromium.org/2011293002
Cr-Commit-Position: refs/heads/master@{#396424}
(cherry picked from commit 3a6cd21dab6a285179b02a05e980091c86545d66)

Review URL: https://codereview.chromium.org/2025623002 .

Cr-Commit-Position: refs/branch-heads/2704@{#678}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/ac93ed2a58541d5bcc6f00497fdc37edef9e42bb/net/dns/mojo_host_resolver_impl.cc

Disabling "Out-of-Process V8 Proxy Resolver"  fixed my issue, now chrome browser is working through pac file after this settings.
1.I would like to understand, i am working in very big enterprise, it is not possible to disable settings on each machine, now is there any fix if we can do it from microsoft active directory's GPO is there any settings anyone has tried out.
2.how do we do the mass changes if we cannot do changes from GPO.

Verified the issue on Windows 7 using chrome latest Dev M52-52.0.2743.19 and observed the site www.microsoft.com able to load fine as expected. Hence adding TE-Verified label.

@sampat: We deployed a temporary fix via GPO by setting these registry keys in a custom ADM file:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ProxyMode"="fixed_servers"
"ProxyServer"="myproxyserver.com:3128"

Retested the above issue on windows 7 with chrome version '51.0.2704.78' and www.microsoft.com website loads fine without any issues. hence adding TE-Verified-51.0.2704.78.

Thank you!

This patch is now pushing out to stable channel in version 51.0.2704.79 for Desktop (Win,Mac & Linux).

amistry@: Could you please close the issue if there is no further work to be done on this and Verified label as per C#56.

amistry: Ping re Comment #58

I can verify this issue is fixed in 51.0.2704.84. Tested on Windows 10, 64-bit.

Steps to verify:
1. Create a proxy.pac file containing the following:
function FindProxyForURL(url, host) {
  alert("Address: " + myIpAddress());
  alert("AddressEx: " + myIpAddressEx());
  return "DIRECT";
}

2. Start chrome on the command line with:
--proxy-pac-url=file:///c:/chrome/proxy.pac --v8-pac-mojo-out-of-process
3. Go to chrome://net-internals, switch to the "Events" page and look for javascript pac alert events.
4. Alert events should contain the real machine IP address and not 127.0.0.1