Unable to reproduce the issue on chrome reported version 64.0.3282.186 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: amazon.com, able to see page loaded successfully without keep spinning and observed logs in chrome://net-internals/#events
2) Again opened other site (for ex: Wikipedia and fb.com), website got loaded.

@Reporter: Please find the attached screen cast for your reference and provide your feedback on it, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks! 

Deleted: 824451.mp4 5.6 MB

	824451.mp4 5.6 MB View Download

We've had some reports of slowness when decrypting the cookie jar (though I've only seen those on Windows, I think). The log you provided is consistent with that, but does not definitely confirm that, either. A workaround would be basically moving away the cookies file, but of course it's annoying since it logs people out from everywhere.

Network bug triager here.

forcepointendpoint@: Thanks for filing the bug, it looks like those request with net_error = ERR_IO_PENDING has the following:
URL_REQUEST_DELEGATE  [dt=17]
t=82678 [st=82678]      DELEGATE_INFO  [dt=17]
                        --> delegate_blocked_by = "extension Forcepoint Endpoint for Windows"
which sounds requests were deferred for significant periods of time by the delegate. (https://codereview.chromium.org/2579933002/) (cc mmenke@ who had experience debugging issues where a delegate defers an request for significant periods of time.)

Have you try to uninstall the extension? Was this still reproducible without the extension? 

Yes, we uninstalled our Chrome extension on customer's machine, there was still the same problem.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the log!  Digging into it, it looks to me like something is delaying the request between start and before the extension looks at the request.  I'll try and do some spelunking tomorrow.

As per comment#4, since this is not reproducible from TE's end and it is already being investigated. Hence adding Triage help label to remove the bug from TE's Unconfirmed triaging bucket

Thanks!

The only explanation I can think of that would create a delay before start but with no "blocked by" netlog text is the blocked_loaders map in RDHI... I'll continue to look into it.

If this is a regression, and you are able to reproduce it on a machine, the best thing would be if you can run a "bisect" so we can narrow down the regression to a particular change (or small set of changes).

Here is how to do that on Windows:

(1) Open a cmd.exe window

Ensure that python is installed by running and on the PATH:
python --version
This should output something like:
Python 2.7.3
(The script doesn't work with version 3.x of python)


(2) Download bisect-builds.py [1] from our source tree.

python -c "import urllib2; import base64; print base64.b64decode(urllib2.urlopen(\"https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT\").read())" > bisect-builds.py


(3) Start the bisection:

python bisect-builds.py -a win -g 508578 -b 520840 --use-local-cache -- --no-first-run --user-data-dir=C:\temp-chrome-profile https://www.google.com


The -g and -b numbers I give in step 3 set the search range between Chrome 63 and Chrome 64 (-g means the last known good version, and -b a known bad version).


[1] https://www.chromium.org/developers/bisect-builds-py

This issue only happened in our customer's specific machine (Windows 10). We cannot reproduce this issue in house (we tried before). We will need to find a chance to test this in our customer's machine.

Thanks

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Leaving this in needs-feedback state, since we can't proceed without more details.

There is also a chance that M66 might make things better.

Does M66 mean latest Chrome browser Version 66.0.3359.139? If so, we can ask our customer try latest one when they still have this issue.

Thanks.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Yes, version 66 <lots of numbers> stable, most people should get updated to it automatically.

A chrome://tracing/ log can sometimes also shed light on performance issues (especially if this is not networking related).

Hi, This is not something we can reproduce on-site, but it has been reported by many of our customers. We're working with a customer to reproduce and collect requested information. Please stay tuned.

vikki.wei:  Any luck getting more information?

Hi, Our customer site has proxy, so bisect didn't work for them. Do you have a version that supports proxy? 

Hrm...Chromium should fully support proxies.

Perhaps vikki.wei means that bisect-build.py fails to download chrome builds because it needs to use a proxy.

At least on Linux, python's urllib respects the http_proxy environment, so adding this before the call to bisect-build.py may do the trick:

set http_proxy='http://myproxy.example.com:1234'

Alternately if the problem is that Chrome is reliant on per-profile proxy settings rather than system proxy settings (the bisect command I gave runs with a fresh profile), the issue could be solved by changing Chrome's command line to include  --proxy-server="myproxy.example.com:1234"

What is the status of this issue?  Has it been resolved in 66 or 67? Having the same problem throughout our organization...

@jeff: This issue is uncategorized and needs more feedback from those experiencing it. Moreover, your slowness may be unrelated to the original poster.

I would suggest opening a new bug (and cross-linking them). On your bug report include a description of the slowness, a NetLog if you think it is network related (https://www.chromium.org/for-testers/providing-network-details).

If this is a regression please run the regression steps in comment #12 (https://bugs.chromium.org/p/chromium/issues/detail?id=824451#c12). That does a bisect between versions 63 and 64. What version range did your regression occur in?

So for our customers this issue is being realized when the machines are dual homed, in this case users who are connected to a VPN client.  It is being seen with Windows 7 & Windows 10 with Chrome versions 64-67.

Going to go ahead and archive this issue - unfortunately, we just don't have enough information to go on here, and the last update from the reporter was a month and a half ago, and we only have so many backlogged bugs we can keep up with at a time.  Feel free to file new bugs (ideally with a bisect, if you can manage it, and if not, at least with a network log, as described in post #30), if the problems persist.

Archiving as per comment #32.