Unable to test this issue from ET end using proxy as we do not have proxy setup as of now. 

Could someone from Internals>Network>Proxy team please have a look at the netlog attached and help in triaging this issue.

Thanks!

How did you set your proxy settings in GNOME? It worked fine here (GNOME 3.26.2 on Fedora 27) both when I set it to "Automatic" and provide a PAC file URL as well as when I set it to "Manual" and provide specific proxy URLs for each protocol. I only tried M65 (the official 65.0.3325.162 RPM) though.

Also, can you confirm you are indeed using GNOME Shell?

The issue only exists in the snapshots found on the Google servers so far, so I believe the 65.0.3325.162 version works correctly, for the 66.0.3350.0 version of Chromium (the current Developer build version for Ubuntu) correctly works.

So far, I have encountered this issue with the 67.0.3369.0 version and later (the current snapshots).

I'm not sure about your request about GNOME Shell. I do use GNOME Shell as my Desktop Environment. The network card itself is managed by a non-GNOME service (GNOME says that the card is unmanaged by it), but its proxy settings are used. I could be mistaken so I'll check again tomorrow.
I login through a tty and I manually run startx, though.

But either way, the older Chromium browser version does find out the proxy settings.

Also, I tried both with manual and automatic modes. Note that even in manual mode Chromium will request credentials even though other processes don't need to.

After further testing, it appears Chromium (67.0.3372.0, build 543327) will properly request the login credentials upon setting the system HTTP_PROXY and HTTPS_PROXY variables, and does not use the GNOME settings.

It has also been noted that even if the GNOME proxy settings are disabled and the environment variables are unset, the Chromium 66.0.3350.0 version will detect proxy settings nevertheless, and so did older snapshots. As such, it appears Chromium now sticks better to the system settings.

I cannot determine if this is a configuration issue from the computers or an actual Chromium change. Either Chromium was able to find proxy settings by itself before, either there have been configuration changes here.

For now, I believe this issue might be on our end, so you may close it. Sorry for the inconvenience.

As per comment#8 closing this issue as Wont-fix and removing Needs-Bisect label. Please feel free to raise a new issue if it is still seen.

Thanks! 

Unfortunately there is an incomprehensible amount of proxy settings options on Chrome desktop linux to pick from, making it difficult to predict expectations vs practice.

Note that there are at least the following Chrome pulls from:

  * Chrome policy (https://www.chromium.org/administrators/policy-list-3)
  * Chrome command line flags (--proxy-server, --proxy-auto-detect, --proxy-bypass-list, --proxy-pac-url, --no-proxy-server)
  * Per-profile Chrome extensions can change proxy settings
  * KDE (kioslaverc)
  * GNOME (gsettings)... or previously, gconf
  * Other historical implementation distinctions due to changes in KDE and GNOME over the years.
  * Environment variable overrides like http_proxy.

Unfortunately the environment variables have the lowest priority, and are essentially useless when Chrome detects a desktop environment whose proxy settings it recognizes (i.e. KDE/GNOME). The env variables are unreliable because some stuff like gnome-terminal can populate them.

The detection of which desktop environment you are using is probably the first place to look in case Chrome isn't even consulting gsettings. That detection is also ugly heuristic that encodes historical conventions.

I would start by looking at the value of these environment variables in order:

  XDG_CURRENT_DESKTOP
  DESKTOP_SESSION
  GNOME_DESKTOP_SESSION_ID

Support for gconf and lazy loading of libgio was recently removed in Chrome 65... but given your regression range doesn't sound like that was your issue.