Firefox 22 uses stale manual proxy settings when configured to use system proxy settings, and system proxy settings are set to "None"

Bug #1194841 reported by Heiko on 2013-06-26
148
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
High
firefox (Ubuntu)
High
Unassigned
Precise
High
Unassigned
Quantal
High
Unassigned
Raring
High
Unassigned

Bug Description

*** WORKAROUND ***

This only applies if you have Firefox configured to use the system proxy settings (which is the default) and have used the manual settings at some point in the past.

1) Open the proxy configuration dialog
   - Edit -> Preferences from the menu, open the "Advanced" pane, select the "Network"
     tab and press the "Settings" button next to "Configure how Firefox connects to
     the Internet"
2) Delete any residual manual proxy configuration settings. To do this, you will need
   to select "Manual", delete the settings, click OK and then re-open the dialog to
   set it back to "System" again

Note, we're going to respin Firefox 22 with the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=817533 , even if upstream aren't

****

I just received the upgrade to FF22 through the update-center. After restarting firefox, I wasn't able to connect to any single web-page.

Checking the 'about:config' network settings, I found out that something had changed the proxy-settings and everything was directed to '134.246...' (don't remember the whole number). After resetting all proxy values, firefox worked again as usual.

Heiko

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: firefox 22.0+build2-0ubuntu0.12.04.1
Uname: Linux 3.2.30-120928-vanilla x86_64
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu17.3
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: heikok 2861 F.... pulseaudio
BuildID: 20130620135945
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xe2e60000 irq 47'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:111d76e7,10280492,00100102 HDA:80862805,80860101,00100000'
   Controls : 30
   Simple ctrls : 13
Channel: Unavailable
CurrentDmesg:
 Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied
 dmesg: write failed: Broken pipe
Date: Wed Jun 26 13:14:53 2013
Extensions: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
IpRoute:
 default via 192.168.0.1 dev wlan0 proto static
 169.254.0.0/16 dev wlan0 scope link metric 1000
 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.13 metric 2
Locales: extensions.sqlite corrupt or missing
MarkForUpload: True
MostRecentCrashID: bp-13ea1db5-8ece-432e-b626-743e32110510
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=22.0/20130620135945 (In use)
RelatedPackageVersions:
 icedtea-7-plugin 1.2.3-0ubuntu0.12.04.2
 rhythmbox-mozilla 2.96-0ubuntu4.2
 totem-mozilla 3.0.1-0ubuntu21.1
RunningIncompatibleAddons: False
SourcePackage: firefox
SubmittedCrashIDs:
 bp-13ea1db5-8ece-432e-b626-743e32110510
 bp-9044c4a6-4c68-4661-951e-83a8a2100308
 bp-44c7c8ad-3f92-41bc-8ce0-9ef032100127
 bp-6e7b33f2-08ce-41cc-ba5b-a83022100127
Themes: extensions.sqlite corrupt or missing
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:

dmi.bios.date: 05/24/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A05
dmi.board.name: 01MCMN
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA05:bd05/24/2011:svnDellInc.:pnLatitudeE6320:pvr01:rvnDellInc.:rn01MCMN:rvrA01:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6320
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

Between Firefox (and TB) 17 and 18b2 the proxy detection broke for the case of autodetection.
I haven't fully debugged it yet but what happens is that
https://mxr.mozilla.org/mozilla-beta/source/toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp#494 can return NS_ERROR_FAILURE what it does in my usecase where there is no GConf,GSettings and nothing is set in environment variables.

Apparently https://mxr.mozilla.org/mozilla-beta/source/netwerk/base/src/nsProtocolProxyService.cpp#1462 was changed in a way that
https://mxr.mozilla.org/mozilla-beta/source/netwerk/base/src/nsProtocolProxyService.cpp#1552
is still reached and something happens within that evaluation.

When I compare with 17 I find:
https://mxr.mozilla.org/mozilla-release/source/netwerk/base/src/nsProtocolProxyService.cpp#1258

So in my use case if no system proxy was found we left Resolve_Internal via NS_OK immediately instead of proceeding to everything below.

This breaks Necko for me on systems not running with Gnome (no GConf/GSettings) and having default settings for using system proxy settings.

Wolfgang, thanks for the bug report and the diagnosis.

Can you be more clear on what the behavior was in ff17 and how that changed in 18? Thanks. (i.e. you got an error before and now it connects without a proxy? or vice versa?)

The code has changed substantially to improve jank, so we need to focus on behavior rather than lines of code. Thanks.

(In reply to Patrick McManus [:mcmanus] from comment #1)
> Can you be more clear on what the behavior was in ff17 and how that changed
> in 18? Thanks. (i.e. you got an error before and now it connects without a
> proxy? or vice versa?)

Ok, sorry for being unclear ;-)

In my test case (and real usage case) I have no proxy at all. I do not have GConf/GSettings so that it falls back to check environment variables.
With FF17 that just worked with proxy.type=5 (the default). With Firefox 18 (actually I noticed the changed behaviour with Thunderbird 18b1) I'm not able to access any HTTP site at all. I only get the error page that my proxy server cannot be accessed.
If GConf is available and used (even if no proxy is set up) everything works fine -> no proxy used at all

Wolfgang, thanks - I still can't reproduce.

here's what I did.. I disable gconf and gsettings like this

 nsresult
 nsUnixSystemProxySettings::Init()
 {
   mSchemeProxySettings.Init(5);
+ return NS_OK;
+
   mGConf = do_GetService(NS_GCONFSERVICE_CONTRACTID);
   mGSettings = do_GetService(NS_GSETTINGSSERVICE_CONTRACTID);

and then I set http_proxy environment var to a real proxy and loaded ipchicken.com to confirm the env var code was being used. And it was.

I then deleted the env var and reran firefox.

I confirmed that nsUnixSystemProxySettings::GetProxyForURI() now returned an NS_ERROR_FAILURE error as you described. But that didn't cause a problem - firefox connected without a proxy just fine - which is the behavior you say ff17 has (and sounds correct to me).

what are we doing differently?

Ok, some more details of testing I did.
First I was thinking it might be related to a patch I'm using in FF and TB which is that one
http://www.rosenauer.org/hg/mozilla/file/31f273919032/mozilla-nongnome-proxies.patch
This is used to make sure that GConf is not used when running under KDE or other non-Gnome Windowmanagers but it looked innocent to me.

To make sure there is nothing in my own compilation I reproduced like this:
(sorry, didn't try FF that way yet)
- install thunderbird 18b1 as provided by mozilla.org
- remove libmozgnome.so from components/binary.manifest
- rename libmozgnome.so to aaalibmozgnome.sobbb in components
By removing libmozgnome both GConf and GSettings is not available in Thunderbird.
This is basically the same what happens when that component cannot be loaded because of deps issues.
Starting up TB and I see immediately a "The proxy server is refusing connections" error.

I'll now try to reproduce with FF18b2 the same way.

Ok, the same steps fail for Firefox.
So actually I was thinking it might be a core Necko issue when it might be some TB specific usage of necko.
Now I do not have an idea what could cause that difference between Firefox and Thunderbird.

I want to figure out if this impacts a platform we support. That obviously excludes distributions where files get deleted or have custom patches :)

I'm leaning towards "not supported" right now - but I'd love to see the case where it is supported.

If the answer is "supported" then I want to hurry in a fix and get it backported to remove regressions.

If the answer is "not supported" it isn't necessarily WONTFIX but we certainly won't set the tracking flags, etc..

what are your proxy environment variables set to (if anything)?

(In reply to Patrick McManus [:mcmanus] from comment #6)
> I want to figure out if this impacts a platform we support. That obviously
> excludes distributions where files get deleted or have custom patches :)

(It's probably time to get that patch committed then since it makes a lot of sense for Linux users.)

What I did to reproduce the issue is removing the mozgnome component. This component is intentionally designed as an optional dependency. To my knowledge Gecko is still supported on systems w/o gconf or gsettings with a bit limited feature set.
I just was too lazy to remove my libgconf stuff from my system.
If Thunderbird is a "supported platform" I do not know nowadays. Neither I don't know why apparently only Thunderbird is affected (I'm going to try Seamonkey now).

(In reply to Patrick McManus [:mcmanus] from comment #7)
> what are your proxy environment variables set to (if anything)?

None.
wolfi@Hygiea:~> env | grep -i proxy
wolfi@Hygiea:~>

alex/lsblakk based on comments 4 5 and 6 I would suggest not tracking for 18.

Just for completeness: Seamonkey is not affected apparently

We definitely support systems without GConf and gsettings-desktop-schemas (which is GNOME-specific AFAIK).
(I don't know whether or not that is equivalent, for purposes of this bug, to removing libmozgnome.so - libmozgnome should now load on all systems because there are no longer gnomevfs or libnotify dependencies, and GConf is accessed through dlopen.)

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #2)
> With Firefox 18
> (actually I noticed the changed behaviour with Thunderbird 18b1) I'm not
> able to access any HTTP site at all. I only get the error page that my proxy
> server cannot be accessed.

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #4)
> Starting up TB and I see immediately a "The proxy server is refusing
> connections" error.

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #5)
> Ok, the same steps fail for Firefox.
> [...]
> Now I do not have an idea what could cause that difference between Firefox
> and Thunderbird.

What is the difference in behavior between Firefox and Thunderbird?

(In reply to Karl Tomlinson (:karlt) from comment #11)
> We definitely support systems without GConf and gsettings-desktop-schemas
> (which is GNOME-specific AFAIK).
> (I don't know whether or not that is equivalent, for purposes of this bug,
> to removing libmozgnome.so - libmozgnome should now load on all systems
> because there are no longer gnomevfs or libnotify dependencies, and GConf is
> accessed through dlopen.)
>
> (In reply to Wolfgang Rosenauer [:wolfiR] from comment #2)
> > With Firefox 18
> > (actually I noticed the changed behaviour with Thunderbird 18b1) I'm not
> > able to access any HTTP site at all. I only get the error page that my proxy
> > server cannot be accessed.
>
> (In reply to Wolfgang Rosenauer [:wolfiR] from comment #4)
> > Starting up TB and I see immediately a "The proxy server is refusing
> > connections" error.
>
> (In reply to Wolfgang Rosenauer [:wolfiR] from comment #5)
> > Ok, the same steps fail for Firefox.
> > [...]
> > Now I do not have an idea what could cause that difference between Firefox
> > and Thunderbird.
>
> What is the difference in behavior between Firefox and Thunderbird?

If that question was to me:
I screwed up. I never was able to reproduce with Firefox but when I opened the bugreport and the behaviour looked very much like Gecko/Necko itself I wrote initially about Firefox instead of Thunderbird while I still was trying to reproduce.

To make it clear:
I cannot observe any erratic behaviour with Firefox 18b2 but I can reproduce with Thunderbird 18b1 easily. Sorry for the confusion but I really hadn't expected a difference there.

(In reply to Patrick McManus [:mcmanus] from comment #9)
> alex/lsblakk based on comments 4 5 and 6 I would suggest not tracking for 18.

Thanks Patrick, not tracking.

I bet bug 713802 plays a role here.

While that's indeed possible I still do not understand the difference between TB and FF.
I build both with
ac_add_options --disable-gnomevfs
ac_add_options --enable-gio
And I guess that the mozilla.org build options for FF18 and TB18 are the same as well?

*** Bug 849792 has been marked as a duplicate of this bug. ***

Created attachment 735214
patch 0

The issue here is that failed system proxy lookups fallback to looking at the manual configs even if we aren't in manual config mode. So manual specific prefs that might be set result in this bug even though we aren't in manual config mode. The fallback should be to direct.

Works fantastic with Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20130412 Firefox/23.0 ID:20130412030828 CSet: 7b8ed29c6bc0

Patrick, can we get a test for it?

*** Bug 849792 has been marked as a duplicate of this bug. ***

This is a regression started with the landing of the patch on bug 824341 for Firefox 22. Can we please get this backported and fixed in Aurora?

(In reply to Henrik Skupin (:whimboo) from comment #21)
> Patrick, can we get a test for it?

This question still stands. Can we get an automated test for this issue?

> This question still stands. Can we get an automated test for this issue?

patches welcome

(In reply to Patrick McManus [:mcmanus] from comment #24)
> > This question still stands. Can we get an automated test for this issue?
>
> patches welcome

Usually we should provide tests for regressions like those. As far as I have seen there were a couple in the proxy related code lately.

So would this be doable as a browser chrome test?

This was originally filed against FF18 - how is this a regression from 824341 in FF22?

(In reply to Alex Keybl [:akeybl] from comment #26)
> This was originally filed against FF18 - how is this a regression from
> 824341 in FF22?

All the bugs we have originally filed against Firefox 22 (see e.g. bug 858854) were duped against this bug. So it seems like a change in Firefox 22 made this problem to widely appear. But Patrick might be able to give more details.

(In reply to Henrik Skupin (:whimboo) from comment #27)

>
> All the bugs we have originally filed against Firefox 22 (see e.g. bug
> 858854) were duped against this bug. So it seems like a change in Firefox 22
> made this problem to widely appear.

Right, a change in the linux system settings proxy implementation uncovered this bug because it used this interface. In addition to using that system settings implementation the user needed some unused stale non-default prefs too. (well, they should have been unused - that was the bug).

The patch here is system independent, but I'm not aware of the issue effecting anything except desktop linux with a dogeared config.

Henrik, you can nom the patch for aurora if you think that's the right thing to do. Do the tracking dance after there is a merged patch is kind of redundant. Either we'll take it or we won't - there isn't much to track at that point.

(In reply to Patrick McManus [:mcmanus] from comment #28)
> Henrik, you can nom the patch for aurora if you think that's the right thing
> to do. Do the tracking dance after there is a merged patch is kind of
> redundant. Either we'll take it or we won't - there isn't much to track at
> that point.

Patrick, I would propose that you request for it given that you wrote the patch and know each and every detail to write up the right assessment for the flag.

Also please let me know about a framework we could use for the test.

(In reply to Henrik Skupin (:whimboo) from comment #29)
> (In reply to Patrick McManus [:mcmanus] from comment #28)
> > Henrik, you can nom the patch for aurora if you think that's the right thing
> > to do. Do the tracking dance after there is a merged patch is kind of
> > redundant. Either we'll take it or we won't - there isn't much to track at
> > that point.
>
> Patrick, I would propose that you request for it given that you wrote the
> patch and know each and every detail to write up the right assessment for
> the flag.

Patch nominations should definitely come from the bug assignee. If this risk outweighs the corner case described in https://bugzilla.mozilla.org/show_bug.cgi?id=849792#c29, we shouldn't take a fix at all.

Comment on attachment 735214
patch 0

[Approval Request Comment] (firefox 22 aurora)
Bug caused by (feature/regressing bug #): 824341

User impact if declined: Linux desktop users who once had configured a manual proxy but are no longer using that configuration may still use the old configuration (probably pointing at a non working proxy) depending on the details of their new proxy settings. (e.g. if their new setting is "use system settings" and the system settings returns an err).

Testing completed (on m-c, etc.): verified on m-c

Risk to taking this patch (and alternatives if risky):

the patch for this is short and low risk. Its downside is that it touches code that runs on all platforms and all transactions in order to make a fix for a very small population.

an alternative would be to backout 824341 (a linux specific change) from aurora-22. The bug fixed by this patch would remain latent, but without 824341 we don't have any reports of it affecting anything.

String or IDL/UUID changes made by this patch: none.

Patrick, the needinfo flag is still valid given that I wait for a response regarding a possible test framework from you. See comment 25.

(In reply to Patrick McManus [:mcmanus] from comment #31)
> User impact if declined: Linux desktop users who once had configured a
> manual proxy but are no longer using that configuration may still use the
> old configuration (probably pointing at a non working proxy) depending on
> the details of their new proxy settings. (e.g. if their new setting is "use
> system settings" and the system settings returns an err).

If this is truly the only affected population and there's no reason to believe there's a FF22 regression, then we won't take the patch. Thanks Patrick.

Patrick, any feedback regarding my question for a test? Thanks.

Heiko (heiko-klein) wrote :
Heiko (heiko-klein) wrote :

I tried to find out something about the proxy-IP address. It might belong to a place where I've been working 2 years ago (February 2011), but only now, with the upgrade to FF22, those settings have been used?

Heiko

Ilya G. Ryabinkin (ileyka) wrote :

The situation is even worse. I'm using ssh SOCKS proxy as well as direct connection to Internet. I switch between them by choosing "system proxy" and "manual proxy" variants. However, after upgrade to Firefox 22 the selection "System proxy" works just like I have "Manual proxy" selection (which is greyed out at this moment). This is incorrect. Please fix.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed

*** Bug 887546 has been marked as a duplicate of this bug. ***

bitinerant (bitinerant) wrote :

When I was upgraded to Firefox 22, pages refused to load with "Firefox is configured to use a proxy server that is refusing connections." Firefox > Edit > Preferences > Advanced > Settings > Configure Proxies... was set to "Use system proxy settings" but in System Settings > Network > Network proxy, Method is set to "None". It was working fine before the Firefox upgrade. The work-around seems to be to set "No proxy" in Firefox.

Lion1969 (lion-box) wrote :

I can confirm setting "Use system proxy settings" really uses parameter from "Manual proxy" setting.
Using "No proxy" option still works.
This was introduced with latest firefox update this morning.

angros47 (angros47) wrote :

The bug affect me, too (I noticed a serious slow-down of browsing, after the upgrade). By going on " Firefox > Edit > Preferences > Advanced > Settings > Configure Proxies", i noticed that when I set "auto-detect proxy", everything works ok, while when I set "use system proxy settings", the settings of the manual proxy configurations are used (although I can't edit them, I have to choose manual configuration to be able to do that).

A workaround is to choose auto-detection of proxy. Another workaround (at least for me), is to choose manual proxy configuration, clean proxy fields, and set back to "use system proxy settings".

So, user who never used proxy before should not be affected by this bug; but user who used a proxy at least once, and then set back configuration to "system proxy settings", after this upgrade will have the proxy enabled again (if the proxy, meanwhile, has been shut down, browsing the web will become impossible)

Ilya G. Ryabinkin (ileyka) wrote :

Looks like this is the same bug already reported in Mozilla bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=817533

Chris Coulson (chrisccoulson) wrote :

Does anyone have "http_proxy" or "all_proxy" set in their environment (you can check with "env | grep proxy"

Chris Coulson (chrisccoulson) wrote :

Oh, sorry, I missed the reference to https://bugzilla.mozilla.org/show_bug.cgi?id=817533, thanks.

I was just looking at that. Yes, it looks like a likely culprit

Changed in firefox (Ubuntu):
importance: Undecided → High
Lion1969 (lion-box) wrote :

no "http_proxy" or "all_proxy" in my env.

Changed in firefox (Ubuntu Precise):
importance: Undecided → High
Changed in firefox (Ubuntu Quantal):
importance: Undecided → High
Changed in firefox (Ubuntu Raring):
importance: Undecided → High
Changed in firefox (Ubuntu):
status: Confirmed → Triaged
Changed in firefox (Ubuntu Precise):
status: New → Triaged
Changed in firefox (Ubuntu Raring):
status: New → Triaged
Changed in firefox (Ubuntu Quantal):
status: New → Triaged
description: updated
description: updated
Chris Coulson (chrisccoulson) wrote :

23.0 beta is already in saucy-proposed, which has the fix

Changed in firefox (Ubuntu):
status: Triaged → Fix Committed
summary: - Upgrade to ff22 enters proxy-settings
+ Firefox 22 uses stale manual proxy settings when configured to use
+ system proxy, and system proxy settings are set to "None"
summary: Firefox 22 uses stale manual proxy settings when configured to use
- system proxy, and system proxy settings are set to "None"
+ system proxy settings, and system proxy settings are set to "None"
Changed in firefox:
importance: Unknown → High
status: Unknown → Fix Released
Chris Coulson (chrisccoulson) wrote :

A fix for this is building in the security PPA, and should be available for people to test soon.

https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa

Robin Roth (robinro) wrote :

This breaks "the internet" for many technical illiterate users. A fix is required ASAP.

This is a nasty bug, since Firefox just fails without any error message after upgrading to version 22. I was affected myself and it took a while to diagnose. One thing puzzles me: why does google.com still work when a broken manual proxy is configured?

(In reply to Gary Houston from comment #36)
> One thing puzzles me: why does google.com still work when a broken
> manual proxy is configured?

probly using ssl and that either takes a slightly different code path or your old stale proxy config didn't cover that.

Yeah, ssl, and my proxy was http only. Thanks.

LaunchpadUser (lpusr) wrote :

Perhaps this bug also affects my problem: after upgraded to Firefox 22 (through the standard Ubuntu update info dialog), my auto proxy config whitelist.pac file is simply ignored! This is highly critical as my children are now able to browse to any website on the internet! Thankfully, I noticed this today as I just migrated one user account from OPera to Firefox.

The only workaround for me is to not use Firefox for the kids. :-(

Patrick, need-info is still valid. You didn't answer my question from comment 35. I hope you will do it at some point! Thanks.

Step to reproduce:

* Launch with firefox -ProfileManager , create new profile, and launch
  firefox with that (new) profile
* Go Preferences -> Advanced -> Network -> Connection -> Settings
* Once choose "Manual proxy configuration", set random http proxy, change port
  (like HTTP Proxy: aaaaaa Port: 8080).
* Then choose *again* "Use system proxy settings"
* Click OK
* Now open some http:// page like http://www.google.com/

*** Bug 888475 has been marked as a duplicate of this bug. ***

*** Bug 888626 has been marked as a duplicate of this bug. ***

(In reply to Mamoru TASAKA from comment #40)
> Step to reproduce:
>
> * Launch with firefox -ProfileManager , create new profile, and launch
> firefox with that (new) profile
> * Go Preferences -> Advanced -> Network -> Connection -> Settings
> * Once choose "Manual proxy configuration", set random http proxy, change
> port
> (like HTTP Proxy: aaaaaa Port: 8080).
> * Then choose *again* "Use system proxy settings"
> * Click OK
> * Now open some http:// page like http://www.google.com/

on Linux (Fedora 19 i686)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 22.0+build2-0ubuntu0.12.04.2

---------------
firefox (22.0+build2-0ubuntu0.12.04.2) precise-security; urgency=low

  * Fix LP: #1194841 - Firefox 22 uses stale manual proxy settings when
    configured to use system proxy settings, and system proxy settings are
    set to "None"
    - add debian/patches/dont-use-stale-manual-proxy-config.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Thu, 27 Jun 2013 16:43:31 +0100

Changed in firefox (Ubuntu Precise):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 22.0+build2-0ubuntu0.12.10.2

---------------
firefox (22.0+build2-0ubuntu0.12.10.2) quantal-security; urgency=low

  * Fix LP: #1194841 - Firefox 22 uses stale manual proxy settings when
    configured to use system proxy settings, and system proxy settings are
    set to "None"
    - add debian/patches/dont-use-stale-manual-proxy-config.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Thu, 27 Jun 2013 16:43:31 +0100

Changed in firefox (Ubuntu Quantal):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 22.0+build2-0ubuntu0.13.04.2

---------------
firefox (22.0+build2-0ubuntu0.13.04.2) raring-security; urgency=low

  * Fix LP: #1194841 - Firefox 22 uses stale manual proxy settings when
    configured to use system proxy settings, and system proxy settings are
    set to "None"
    - add debian/patches/dont-use-stale-manual-proxy-config.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Thu, 27 Jun 2013 16:43:31 +0100

Changed in firefox (Ubuntu Raring):
status: Triaged → Fix Released
Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released

*** Bug 886973 has been marked as a duplicate of this bug. ***

(In reply to Henrik Skupin (:whimboo) from comment #25)
>
> So would this be doable as a browser chrome test?

you can probably write an xpcshell test that sets some http proxy address along with a PROXYCONFIG_MANUAL setting and then test the results of a nsIProtocolProxyService.asyncResolve invocation to make sure the pi.type is not http.

Marian Hello (marian-hello) wrote :

till valid in Ubuntu 16.04.1 and Firefox 49.0+build4-0ubuntu0.16.04.1

How to reproduce (set some invalid host and port

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host 'nonexistinghost'
gsettings set org.gnome.system.proxy.http port 9999
gsettings set org.gnome.system.proxy mode 'none'

Expected outcome: FF will not use any proxy and any website will be normally accessible.
Actual outcome: Visiting any page result in: The proxy server is refusing connections

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.