I was also able to replicate the issue on Chrome Canary Version 73.0.3642.0 (Official Build) canary (64-bit)

I've replicated this issue on the following:

Ubuntu 18.04 Chromium 71
Ubuntu 18.04 Chromium 73
Windows 10 Chrome 71
Windows 10 Chrome 73

I don't follow those repro steps, but I expect the useful information would be a NetLog captured on Chrome 70, and one captured on Chrome 71

https://www.chromium.org/for-testers/providing-network-details

If the problem is in the extension not applying the intended proxy post-restart, the log would show which proxy was used.

I'm not sure if a NetLog will help since I can only reproduce this issue when opening the browser for the first time. Is there a way to turn on NetLog or to log network activity from the moment the browser is opened?

Also, if there's anything in the repro steps I can help clarify, I'm more than happy to  help. 

Here's a more complete list of steps. 

On Chrome Canary:
1. Install the Private Internet Access extension from: https://chrome.google.com/webstore/detail/private-internet-access/jplnlifepflhkbkgonidnobkakhmpnmh/related?hl=en
2. Click on the popup button in the browser toolbar (Should be a red robot)
3. Log into the extension. (I can provide credentials if needed via email)
4. Enabled the proxy by clicking on the toggle button (should be default to NYC)
5. Verify that an google account is logged into the browser and that syncing is on.
6. Restart the browser
7. The account syncing will be paused. 

You can specify the --log-net-log flag to Chrome (See the "Advanced: Logging on startup" part of that link).

The other useful debugging step would be to try and bisect to a smaller Chrome regression window. Normally https://www.chromium.org/developers/bisect-builds-py offers an easy way to do that. However in your case it sounds like this involves a Chrome restart, which will cause issues for that script.

On your Canary test, another factor is the Network Service was enabled. Try turning that off from chrome://flags/#network-service

Also note that --log-net-log takes the form --log-net-log=path-to-file, so "--log-net-log" alone won't do what you want. The resulting file is what contains the useful information.

The problem with bisect-builds is when you quit Chrome it advances to next version, so tests involving a restart will be problematic.

Hello!

Here's a copy of the NetLog. This was taken on a browser startup where previously, the extension was installed and a proxy was set and an account was synced. 

I'm not familiar with this file so any help would be appreciated. 

I'm currently using: https://netlog-viewer.appspot.com/
To view the events in the file but I can't seem to pinpoint what is going wrong here. 

Deleted: net-log.json 1.5 MB

net-log.json 1.5 MB View Download

Here's a copy of the NetLog with the Network Service disabled. I still get the same issue though.

Deleted: net-log-no-network-service.json 1.3 MB

net-log-no-network-service.json 1.3 MB View Download

Can you provide a log file from a working version of Chrome too?

In the failed NetLogs, it looks like the proxy "HTTPS https-us-siliconvalley.privateinternetaccess.com:80" is being used when issuing the request for sign-in (https://accounts.google.com/*), which I presume is working as intended.

(There is a bit of churn in when the proxy settings are changed by the extension, but doesn't seem to have impacted those requests).

The connections to accounts.google.com do show that proxy authentication was requested:

   Proxy-Authenticate: Basic realm="Private Internet Access"

Perhaps this is where things went wrong?

Are you expecting to get a dialog prompt to enter credentials for proxy authentication?

To answer your question, we are not expecting a dialog prompt to enter credentials. We're relying on the onAuthRequired event handler to supply the credentials via a credentials stored in localStorage. 

I will try to see if I can find a working copy of Chrome and get the NetLog from that as well. 

A interesting note, I switch the account on canary from my personal account to my work account, and deleted all cached data. The new account only has the PIA extension installed, and now the problem seems more intermittent. Sometimes the pause will flicker for a quick second, other times it is permanent. 

Here's a NetLog from Canary where the proxy is enabled, account sync is on, and I'm connecting to New York Rather than Silicon Valley. I'm currently located in Hawaii, and it seems like the farther away I am, the more likely it will work. Anything on the western coast leaves the account syncing in a permanent paused state. But outside of that radius, New York for example, will be paused for about a second or so, then will display as syncing. 

The attached file is from the example above where I am connected to NY and the account syncing pauses for a second then goes back to a syncing state. 

Deleted: net-log-no-network-service-newyork.json 1.0 MB

net-log-no-network-service-newyork.json 1.0 MB View Download

I would be suspicious of the proxy authentication.

Are you the extension developer? If so, try tracing to see if the extension is getting onAuthRequired() called at the expected time, and whether it is returning the same result.

That east-coast vs west-coast proxy servers give you a different behavior could perhaps just be a symptom of timing issue. Where for slower to respond proxy servers, we end up finishing some initialization and then setting the proper credentials via extension, whereas for the fast the respond proxy it does not?

I am the extension developer, well, one of them. Is there a good tools to use for tracing and matching up with the NetLogs? I'm currently just using console.log to catch any incoming onAuthRequired events and just printing out the detail object. So far, I haven't seen anything from accoutns.google.com. The earliest onAuthRequired event seems to be the call to get our list of servers. This is event number 69 in the most recent file I've attached in Comment 13. 

Any url requests before that aren't shown in dev tools. I think it may have to do with the fact that "reserved" urls that deal with chrome directly, either aren't handled by our onAuthRequired event handler or just simple isn't shown in the devTools. I'm not sure what's more correct here. 

It does seem like a timing issue of some sort. We were leaning toward that but wasn't exactly sure since we didn't have the tools to really dig into what was going on in chrome pre extension initialization. If it is a timing issue, I'm not sure what the path forward would be. Does Chrome offer any sort of solution in terms of bootstrapping the onAuthRequired quicker since I believe all these call are made in chrome before the extension is even warmed up? 

So it looks like the difference between the two files, is that in the earlier failed file, event number 122 is a url request to log out the user:

122: URL_REQUEST
https://accounts.google.com/Logout?source=ChromiumAccountReconcilorDice

I'm not sure what's triggering that. In both files, two calls to accounts.google.com are made, the first one always fails, but the second (having enough time to bootstrap the extension) makes it through. In the failed file, somewhere between the second call to the accounts.google.com, and event 122, something happens that tells chrome that my account is no longer valid and attempts to log out my account. So it may not be a timing issue? I will keep investigating but I am unfamiliar with how chrome handles it internal account authentication. 

Reporter@ Thanks for the issue.

This issue seems to be duplicate of the issue 914672. Hence merging this issue to issue 914672.
Please feel free to undupe if it is not similar.

Thanks..