I just updated to the latest Nightly and found that my main profile was getting "The proxy server is refusing connections" errors when trying to load any page. I checked my proxy settings and found that they were set to "use system proxy settings". I looked in gnome-control center, and it has no proxy servers setup. I tried in a different profile and was surprised to find that even with the proxy server settings the same, the new profile was able to load pages. Even with my main profile in safe mode I continue to hit this issue. Maybe related to bug 824341, which landed recently and touches Linux proxy server settings?

Could you please send me the output of $ env Thanks a lot

➜ ~ env | sort bbc=buildbot-configs bc=buildbotcustom cl=/home/bhearsum/Mozilla/checkouts/clean co=/home/bhearsum/Mozilla/checkouts COLORTERM=gnome-terminal CVSROOT=:ext:bhearsum%mozilla.com@cvs.mozilla.org:/cvsroot DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-FtiBMEFjBR,guid=4f76ea163465eab133c48527513dcb3e DEFAULTS_PATH=/usr/share/gconf/awesome.default.path DESKTOP_SESSION=awesome DISPLAY=:0 EDITOR=vim GDMSESSION=awesome gh=/home/bhearsum/Mozilla/checkouts/github GPG_AGENT_INFO=/tmp/gpg-PldzWH/S.gpg-agent:2653:1 GREP_COLOR=1;32 GREP_OPTIONS=--color=auto GTK_MODULES=overlay-scrollbar HG_SHARE_BASE_DIR=/home/bhearsum/usr/hg HOME=/home/bhearsum _JAVA_AWT_WM_NONREPARENTING=1 LANG=tl_PH.UTF-8 LANGUAGE=tl:en LC_ADDRESS=tl_PH.UTF-8 LC_CTYPE=tl_PH.UTF-8 LC_IDENTIFICATION=tl_PH.UTF-8 LC_MEASUREMENT=tl_PH.UTF-8 LC_MONETARY=tl_PH.UTF-8 LC_NAME=tl_PH.UTF-8 LC_NUMERIC=tl_PH.UTF-8 LC_PAPER=tl_PH.UTF-8 LC_TELEPHONE=tl_PH.UTF-8 LC_TIME=tl_PH.UTF-8 LESS=-R LOGNAME=bhearsum LSCOLORS=Gxfxcxdxbxegedabagacad MANDATORY_PATH=/usr/share/gconf/awesome.mandatory.path OLDPWD=/home/bhearsum/Mozilla/checkouts/clean/buildbot-configs/mozilla/l10n ORBIT_SOCKETDIR=/tmp/orbit-bhearsum PAGER=less patches=/home/bhearsum/Mozilla/patches PATH=/home/bhearsum/bin:/home/bhearsum/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/bhearsum/bin:/home/bhearsum/bin PWD=/home/bhearsum PYTHONDONTWRITEBYTECODE=1 SHELL=/bin/zsh SHLVL=1 SSH_AGENT_PID=2652 SSH_AUTH_SOCK=/tmp/ssh-NWkB8cYzxrOe/agent.2568 TERMINATOR_UUID=urn:uuid:491bb572-9e0c-46d2-bd16-18c11599b673 TERM=xterm UBUNTU_MENUPROXY=libappmenu.so USER=bhearsum _=/usr/bin/env VIRTUALENVWRAPPER_HOOK_DIR=/home/bhearsum/.virtualenvs VIRTUALENVWRAPPER_LOG_DIR=/home/bhearsum/.virtualenvs VIRTUALENVWRAPPER_PROJECT_FILENAME=.project WINDOWID=10485764 WORKON_HOME=/home/bhearsum/.virtualenvs XAUTHORITY=/home/bhearsum/.Xauthority XDG_CONFIG_DIRS=/etc/xdg/xdg-awesome:/etc/xdg XDG_DATA_DIRS=/usr/share/awesome:/usr/local/share/:/usr/share/ XDG_RUNTIME_DIR=/run/user/bhearsum XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SESSION_COOKIE=c7ca0c9c5f0e5b7047ce9b5c0000000a-1363004220.368085-848102237 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0

Oke there is definitly no proxy in your environment variables. could please give me the value of /system/http_proxy/use_http_proxy and /system/http_proxy/host (use gconf-editor) Btw do you use gnome3 or gnome2?

(In reply to David Geistert (:d3f3kt) from comment #3) > Oke there is definitly no proxy in your environment variables. > could please give me the value of /system/http_proxy/use_http_proxy and > /system/http_proxy/host (use gconf-editor) > > Btw do you use gnome3 or gnome2? I use awesomewm, but I have gnome-settings-daemon 3.4.2-0ubuntu15 running. use_http_proxy is unchecked, host is empty. Here's the full settings: https://people.mozilla.com/~bhearsum/sattap/ec71a286.png

I use almost the same configuration as Ben, but no such issues with the latest nightly (20130311030946). $ gconftool-2 -g /system/http_proxy/use_http_proxy false $ gconftool-2 -g /system/http_proxy/host (returns empty line)

Sorry for the slow reply. I was testing a lot and can't detect the bug. My only guess is that Ben has set a proxy in dconf-editor in org.gnome.system.proxy.http If there is no proxy I dont know how I can help you

I've got nothing under org.gnome.system.proxy :(

Oke I wrote a debug patch for you. http://www.pastebin.mozilla.org/2209600 Can you please patch toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp and recompile firefox. After that please send me the console output of firefox. Thanks

(In reply to David Geistert (:d3f3kt) from comment #8) > Oke I wrote a debug patch for you. > http://www.pastebin.mozilla.org/2209600 > > Can you please patch toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp > and recompile firefox. After that please send me the console output of > firefox. > > Thanks I pushed this to try: https://tbpl.mozilla.org/?tree=Try&rev=83ec272217f1 I'll give it a try with both profiles when it's done.

The new profile, that isn't experiencing the problem, gave this output: ➜ firefox ./firefox -P -no-remote check GSetting for proxy no GSettings proxy found no env proxy found My existing profile, that's hitting this bug, gave the same output, but it did so at least 30 times, eg: ➜ firefox ./firefox -P check GSetting for proxy no GSettings proxy found no env proxy found*** UTM:SVC TimerManager:registerTimer - id: browser-cleanup-thumbnails check GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found no env proxy foundcheck GSetting for proxy no GSettings proxy found

I'm a new at firefox developing but I'm quite sure that bug 824341 has nothing to do with that bug. If you back out the patch for bug 824341 do you have the same problems?

(In reply to Ben Hearsum [:bhearsum] from comment #2) > ➜ ~ env | sort Perhaps worth checking "perl -pe 's/\0/\n/g' /proc/<pid>/environ | grep -i proxy" with the pid of the firefox process behaving differently, just in case there is something dynamic or process-specific. (In reply to Ben Hearsum [:bhearsum] from comment #10) > My existing profile, that's hitting this bug, gave the same output, but it > did so at least 30 times, eg: I'm not surprised you see this 30 times as these methods are called for every http request (or some similar granularity).

One thing that is different since the patch in bug 824341 is that GetProxyForURI will now be returning NS_ERROR_FAILURE (the same as what is returned for those without GSettings) instead of NS_OK with explicit "DIRECT". I wouldn't expect that to make a difference but perhaps it does for some reason. Any extensions that could be interacting here?

(In reply to Karl Tomlinson (:karlt) from comment #12) > (In reply to Ben Hearsum [:bhearsum] from comment #2) > > ➜ ~ env | sort > > Perhaps worth checking "perl -pe 's/\0/\n/g' /proc/<pid>/environ | grep -i > proxy" with the pid of the firefox process behaving differently, just in > case there is something dynamic or process-specific. Nothing of note here: ➜ ~ perl -pe 's/\0/\n/g' /proc/28879/environ | grep -i proxy UBUNTU_MENUPROXY=libappmenu.so > (In reply to Ben Hearsum [:bhearsum] from comment #10) > > My existing profile, that's hitting this bug, gave the same output, but it > > did so at least 30 times, eg: > > I'm not surprised you see this 30 times as these methods are called for > every http request (or some similar granularity). Ah, ok. That must've been one per tab in my session then. (In reply to Karl Tomlinson (:karlt) from comment #13) > One thing that is different since the patch in bug 824341 is that > GetProxyForURI will now be returning NS_ERROR_FAILURE (the same as what is > returned for those without GSettings) instead of NS_OK with explicit > "DIRECT". > > I wouldn't expect that to make a difference but perhaps it does for some > reason. > > Any extensions that could be interacting here? I've got a bunch installed, only HTTPS-Everywhere seems like it would be potentially interfering. I'm also able to reproduce the problem in safe mode. The extensions that are installed and enabled are: A Bit Better RTM Adblock Plus BugzillaJS Bugzilla Tweaks Check4Change FoxClocks HTTPS-Everywhere It's All Text! Lazarus: Form Recovery Menu Icons Plus PDF Viewer Status-4-Evar Stylish Tile Tabs

(In reply to Ben Hearsum [:bhearsum] from comment #14) > I'm also able to reproduce the problem in safe mode. Oh, sorry. I somehow missed this in comment 0. I guess that means extensions are not involved, and the only difference between profiles is meant to be preferences. I don't know what other preferences could be involved here. I guess look for proxy and maybe netw.

NSPR_LOG_MODULES=proxy:5 in the environment with a debug build may provide some more information. I'd expect multiple lines with "pac thread callback did not provide information 0". Anything else could be a clue.

I tried a debug build and got this after switching to the system proxy and trying to load a page: 204076864[2544950]: pac thread callback did not provide information 0 204076864[2544950]: DisableProxy socks localhost:9999 1909 ++DOMWINDOW == 111 (0x4502078) [serial = 135] [outer = 0x4a6d748] WARNING: attempt to modify an immutable nsStandardURL: file ../../../../netwerk/base/src/nsStandardURL.cpp, line 1205 204076864[2544950]: All proxies are disabled, so trying all again 204076864[2544950]: All proxies are disabled, so trying all again 204076864[2544950]: pac thread callback did not provide information 0 204076864[2544950]: DisableProxy socks localhost:9999 1910 What's interesting about that to me is that localhost:9999 is listed in the disabled manual proxy section. In fact, if I switch to my working profile, enter a proxy into the "manual proxy" section, then select "use system proxy settings", I can reproduce the bug in it.

Please try this patch: http://www.pastebin.mozilla.org/2214479

(In reply to David Geistert (:d3f3kt) from comment #18) > Please try this patch: > http://www.pastebin.mozilla.org/2214479 Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=47947502e09f

(In reply to Ben Hearsum [:bhearsum] from comment #19) > (In reply to David Geistert (:d3f3kt) from comment #18) > > Please try this patch: > > http://www.pastebin.mozilla.org/2214479 > > Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=47947502e09f This patch doesn't fix the issue.

(In reply to Ben Hearsum [:bhearsum] from comment #20) > (In reply to Ben Hearsum [:bhearsum] from comment #19) > > (In reply to David Geistert (:d3f3kt) from comment #18) > > > Please try this patch: > > > http://www.pastebin.mozilla.org/2214479 > > > > Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=47947502e09f > > This patch doesn't fix the issue. Sorry but then I don't know, why it doesn't work. The output from the debug patch says, that no proxy is in use. And The patch I sended you says firefox explicit that it have to connect direct when no environment proxy is set.

(In reply to David Geistert (:d3f3kt) from comment #21) > (In reply to Ben Hearsum [:bhearsum] from comment #20) > > (In reply to Ben Hearsum [:bhearsum] from comment #19) > > > (In reply to David Geistert (:d3f3kt) from comment #18) > > > > Please try this patch: > > > > http://www.pastebin.mozilla.org/2214479 > > > > > > Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=47947502e09f > > > > This patch doesn't fix the issue. > Sorry but then I don't know, why it doesn't work. The output from the debug > patch says, that no proxy is in use. And The patch I sended you says firefox > explicit that it have to connect direct when no environment proxy is set. The patch as provided won't work: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsProtocolProxyService.cpp#1540 shows that the NS_ERROR_FAILURE that is returned will cause the proxy string to not be processed.

I can reproduce with Firefox 19.0: 1) Ensure that libgconf-2.so.4 and gsettings-desktop-schemas are not installed (or move them out of the way temporarily. 2) Set up a manual proxy pointing at nothing. 3) Select "use system proxy settings". 4) try to load www.mozilla.org. Actual result: "The proxy server is refusing connections" So the bug existed prior to bug 824341, though changes to fix bug 824341 made this bug demonstrate for Ben.

Is there anything else I can do to help here?

Looks like before http://hg.mozilla.org/mozilla-central/rev/dcae72a1333c#l21.656 nsProtocolProxyService::Resolve_Internal would not fall back to other settings if mSystemProxySettings->GetProxyForURI() failed, but I'm not familiar with this code. I think that makes this a duplicate of bug 817533.

Doesn't the user impact here outweigh what was trying to be fixed in bug 824341?

(In reply to Alex Keybl [:akeybl] from comment #28) > Doesn't the user impact here outweigh what was trying to be fixed in bug > 824341? No. This bug only affected users that had added manual proxy settings through the "Advanced" preferences tab. It also already existed for every DE except one (unless they happened to have GNOME libs installed on the same system), with changes in bug 824341 merely making the behavior consistent across all desktops. Bug 817533 affected everyone with GNOME libs installed. Patrick has fixed this anyway - thanks very much.

(In reply to Karl Tomlinson (:karlt) from comment #29) > Bug 817533 affected everyone with GNOME libs installed. Sorry, I meant bug 824341 affected everyone with GNOME libs installed, even at default preference settings.