Closed Bug 849792 Opened 11 years ago Closed 11 years ago

firefox uses manual proxy even when "use system proxy settings" is selected

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 817533

People

(Reporter: bhearsum, Assigned: karlt)

References

Details

(Keywords: regression) 

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?
Assignee: nobody → karlt
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.
Summary: "use system proxy settings" behaviour differs between profiles → firefox uses manual proxy even when "use system proxy settings" is selected
(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.
Assignee: karlt → nobody
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Doesn't the user impact here outweigh what was trying to be fixed in bug 824341?
Status: RESOLVED → REOPENED
status-firefox21: --- → unaffected
tracking-firefox22: --- → ?
tracking-firefox23: --- → ?
Resolution: DUPLICATE → ---
Assignee: nobody → karlt
Keywords: regression
(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.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → DUPLICATE
(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.
You need to log in before you can comment on or make changes to this bug.