Closed Bug 821655 Opened 12 years ago Closed 12 years ago

System proxy settings via $http_proxy/$HTTP_PROXY are not recognized anymore

Categories

(Firefox Build System :: General, defect)

All
Linux
defect
Not set
major

Tracking

(firefox17 unaffected, firefox18- affected, firefox19- affected, firefox20- affected)

RESOLVED WORKSFORME
Tracking Status
firefox17 --- unaffected
firefox18 - affected
firefox19 - affected
firefox20 - affected

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: regression, user-doc-needed)

While setting up our new ESX cluster for Mozmill tests on bug 773116 we have noticed that the system proxy is not detected anymore by Firefox on Ubuntu. The original implementation happened for Firefox 4.0 and was covered by bug 66057.

So I did some more testing for now and have seen that the system proxy settings are successfully retrieved up to Firefox 17.0.1, which are our builds from FTP. The first build which is failing here is 18.0b1. Surprisingly the default Firefox installation which is 17.0.1 on Ubuntu fails too. But I'm not sure which modifications they have made. So I would concentrate on our builds for now.

This is a major regression which should not be shipped with Firefox 18.0. Setting appropriate blocking flags.

I will dig through builds to find out the real regression range for it.
Regressed between 2012-09-27 and 2012-09-28 on mozilla-central.

PASS: http://hg.mozilla.org/mozilla-central/rev/b038e9e2023f
FAIL: http://hg.mozilla.org/mozilla-central/rev/895f66c4eada

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b038e9e2023f&tochange=895f66c4eada

So without having checked the patches in detail I can only see those two bugs which could have regressed the system proxy feature: bug 791531, bug 769764.
So bug 791531 is about PAC which is not involved in this bug report. I would blame bug 769764 then and especially the following changeset:

https://hg.mozilla.org/mozilla-central/rev/dcae72a1333c
Blocks: 769764
Not sure if this could also affect OS X but I can't test this given I don't have access to such a box in SCL3. Adrian, would you have a chance to do that?
Can we please get this fixed as soon as possible on all the affected branches given that it also blocks our current Mozmill automation efforts.
Whiteboard: [qa-automation-blocked]
henrik can you make the STR more specific please, thank you. System proxies on linux were indeed in the test matrix, so let's figure out what the difference is.

* what ubuntu distribution are you reporting the bug against

* how are you setting the sytem proxy configurtion (there is more than 1 way).. through env variable - through a gconf dialog? pac or http proxy? (https proxy?) Please be specific.

* confirm that the firefox connection proxy settings are set to "use system proxy"
(In reply to Patrick McManus [:mcmanus] from comment #5)
> * what ubuntu distribution are you reporting the bug against

I can see it at least with 12.04 and 12.10. Also builds on Fedora are affected.

> * how are you setting the sytem proxy configurtion (there is more than 1
> way).. through env variable - through a gconf dialog? pac or http proxy?
> (https proxy?) Please be specific.

We add them /etc/environment:

http_proxy=http://proxy.dmz.phx1.mozilla.com:3128/
https_proxy=http://proxy.dmz.phx1.mozilla.com:3128/
ftp_proxy=http://proxy.dmz.phx1.mozilla.com:3128/
no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"
HTTP_PROXY=http://proxy.dmz.phx1.mozilla.com:3128/
HTTPS_PROXY=http://proxy.dmz.phx1.mozilla.com:3128/
FTP_PROXY=http://proxy.dmz.phx1.mozilla.com:3128/
NO_PROXY="localhost,127.0.0.1,localaddress,.localdomain.com"

> * confirm that the firefox connection proxy settings are set to "use system
> proxy"

Those are set correctly.
I suspect this changed with bug 713802, where Mozilla builds started using --enable-gio like Ubuntu builds.

The designed behavior is if gsettings-desktop-schemas has a proxy setting then that is used.  If that is not present, then GConf is used if that is available.  If neither of those are available then the environment variables are checked.

What changed in bug 713802 is that gsettings-desktop-schemas is now checked.  Also some gnome-vfs dependencies on the GConf module were also removed, which may have made that start working.  With 12.04 and .10, I suspect it is GSettings that are relevant here.

The logic hasn't really changed.  It's just that we check for system settings in new places because systems are not supporting GConf now.

There may be a case for using env vars if set, but environment variables have less control than system settings, so it is quite likely that someone has GSettings and env settings, intending that the GSettings are used in apps that can support it.

There may be other ways to determine what to do when there are multiple settings, but this would be a new feature rather than restoring any old behaviour.
Blocks: 713802
No longer blocks: 769764
Component: Networking → Build Config
Doesn't sound like this is really a regression based upon comment 7, just something that needs to change in our testing configs. Please re-nominate if we've got that wrong.
Thanks Karl. Looks like that works now using the network proxy settings you can reach via 'system settings -> network' on both Ubuntu and Fedora.

We should check that we have user documentation available for that change so others don't run into the same issue.
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: user-doc-needed
Resolution: --- → WORKSFORME
Please be aware that I also see this behavior with stock Firefox 17.0 on Ubuntu 12.04. So it's before our code was part of an official build. Most likely Ubuntu added some patches?
I expect Ubuntu was building with enable-gio.  about:buildconfig would confirm that.
(In reply to Karl Tomlinson (:karlt) from comment #12)
> I expect Ubuntu was building with enable-gio.  about:buildconfig would
> confirm that.

Yup, Firefox 17.0.1 in Ubuntu 12.04 has that flag set in my about:buildconfig.
Whiteboard: [qa-automation-blocked]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.