Comment 5 explains why this is not optimal for us: https://code.google.com/p/chromium/issues/detail?id=46252#c5

I replied on comment 6 why that reasoning was wrong:  https://code.google.com/p/chromium/issues/detail?id=46252#c6

See https://code.google.com/p/libproxy/wiki/HowTo.

The order of the checking is clearly defined:
 1. USER
 2. SESSION
 3. SYSTEM
 4. envvar
 5. wpad
 6. direct

And by SESSION it means checking if the running session is either GNOME or KDE:

GNOME (checks for DESKTOP_SESSION == gnome):
https://code.google.com/p/libproxy/source/browse/trunk/libproxy/modules/config_gnome.cpp

KDE (checks for DESKTOP_SESSION == KDE_FULL_SESSION)
https://code.google.com/p/libproxy/source/browse/trunk/libproxy/modules/config_kde4.cpp

See?

looks like the module doesn't load in filesystem order but sorts the module filename, at least: https://code.google.com/p/libproxy/source/browse/trunk/libmodman/module_manager.cpp

evan@, maybe you should take a second look?

Also, see https://code.google.com/p/libproxy/wiki/ConfigurationLogic. Chromium is mentioned there so it looks like they have this use-case in mind.

If someone wants to write a patch, I'd take a look at it.

It sounds like the PAC stuff in particular is pretty ugly though: it depends on webkitgtk which is separate from our webkit.

See also pacrunner, which has a libproxy-compatible library but it just sends a query to the pacrunner dæmon over D-Bus. Which means the PAC file is loaded *once* in *one* process, which is a lot saner.

That's what we'll be using in MeeGo, since libproxy itself seems to have jumped the shark with the move to C++ etc. But that's an implementation detail. The important point is that all http-using applications should be using the libproxy API to use the correct system-wide proxy settings. You can worry about certain implementations which might not use your preferred JS implementation, or which might occasionally give results other than the ones you'd have made up for yourself -- but the point is that this should *NOT* be done differently in every http-using application which thinks it knows best. It should be consistent across the system.

I would much prefer Chrome to be consistent with the rest of the system, and *wrong*, than I would for it to get things right for itself and mask the fact that the system proxy settings are broken.

Deprecating HelpWanted label.

I agree on this feature request. Additionally, this would immediately give you the solutionin gnome3 that chromium now does not get proxy settings (moved from gconf to gsettings).

Instead of implementing this in every application: libproxy has now support for this (release should be soon.. it's in svn already) and all apps using libproxy 'just get it right again'.

Attached is an example patch of Chrome talking to PACrunner using DBus Glib API to obtaining proxies.  It has been tested against PACrunner 0.3-8.1.

0001-Use-PACrunner-to-resolve-proxy-for-an-URL.patch 8.4 KB   View   Download

Chrome version 12.0.715 (cf6e760) was patched.

There is something fundamentally wrong with using GConf for setting proxies: A proxy is a network property, not a user preference. You will have different proxies for different networks. Your VPN proxy *is* different than your home network proxy. 
You can even have different proxies for different IPs or IP ranges.PACrunner fixes that fundamental problem, through libproxy. 

So as long as your network applications use GConf as their centralized proxy setting, they will keep on ignoring that problem. It hits you really quickly if you're switching between 3G and WiFi for example.

(Un-ccing myself from bugs.)

This happens with MATE as well. (MATE 1.4.1 running on openSUSE 12.2)

http://susepaste.org/32618052

(No comment was entered for this change.)

(No comment was entered for this change.)