Assigning to Steven to check where this is located. This is strange.

Sadly our cros proxy configuration expertise is sadly lacking these days.

+atwilson@, +emaxx@ - Is anyone in the enterprise group familiar with proxy configuration these days?

I can poke at this when I have a chance, but it won't be any time soon.

aashutoshk@, can you confirm whether or not this is also a problem with old settings (chrome://settings-frame)?

Is this actually a beyondcorp issue? - I just reproduced this on my corp workstation:

1) Go to chrome:net-internals/#proxy and see that I have a proxy set by the beyondcorp extension.
2) open an incognito window, go to chrome:net-internals/#proxy, and see no proxy

So at least in this case in Linux chrome, proxy setting isn't getting carried over.

Confirmed on a local ToT build with target_os="chrome" and on 600.3105.0. URLs visited in the Incognito tabs bypass both manually and policy configured proxies (tested by visiting sites like whatismyip), and chrome:net-internals#proxy displays "Use DIRECT connections" in Incognito.

Therefore elevating the bug priority.


RE comment 3:

> +atwilson@, +emaxx@ - Is anyone in the enterprise group familiar with proxy configuration these days?

We definitely don't have any dedicated experts either. I will try to help though.

> aashutoshk@, can you confirm whether or not this is also a problem with old settings (chrome://settings-frame)?

Both "old" and "new" Settings URLs are always opened in non-Incognito windows; they can't be opened in Incognito. But chrome://net-internals works from Incognito and reveals the issue (although, as per my testing, this is not a UI glitch - URL's are actually bypassing proxy).


Re comment 4:

> Is this actually a beyondcorp issue? - I just reproduced this on my corp workstation

I don't think it's limited to beyondcorp - from my testing, per-protocol proxy settings are disregarded over as well.

+mmenke: Do you think this can be related to  issue 734565 ?

It could be - it depends on whether this works through Chrome's code and setting prefs in a cross-platform manner, or via ChromeOS's code.

Re comment 7: I repeated the testing after a fresh fetch of the code (which includes the fix for  issue 734565 ), but the problem with Incognito mode is still there. So apparently it's a separate bug...

We haven't confirmed that my patch fixes  issue 734565  yet.

If you turn off wifi and then turn it back on, does the issue resolve (Or unplug the ethernet cable temporarily)?  That workaround was mentioned on  issue 734565 .  If it works, it's presumably the same issue.

BTW, suspicious that we have two proxy-related P0s cropping up. Can we have someone on the QA side do a bisect to figure out when this broke?

I'm still not convinced this is a separate issue.  But I don't think it's too suspicious when there are no unittests or integration tests of ChromeOS's proxy configuration code.

Confirmed that the workaround with disconnecting and connecting back the default network works - after that the previously opened Incognito tabs start using the proxy.

Marking this a duplicate - given that also fixes this issue, and the fact that I don't think that my fix for  issue 734565  actually worked (For reasons I understand), marking this a dupe.  Going to look into unit tests this time, so may be a couple days before I land a fix.