Proxy settings should be set to "auto-detect" by default

Bug #48445 reported by Kyromaster on 2006-06-05
10
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Won't Fix
Low
firefox (Ubuntu)
Wishlist
Unassigned
firefox-3.0 (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: firefox

If I install a fresh ubuntu the settings for firefox should be set to "auto-detect proxy settings for this network" so a proxy in my network is auto-detected using WPAD.
If the user has no proxy in the network this wont have any side-effects.

User-Agent: Mozilla/5.0 (Windows; U; Win98; pl-PL; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Many networks at Universities and Companys make use of proxy autodetection in
MSIE. It should be the same in Firefox. Instead, users have to set it by
themseves, which is against "auto-detection" magic.

Reproducible: Always

Steps to Reproduce:
look into Options->General->Connection settings

Actual Results:
"Direct connection to Internet" is set.

Expected Results:
Should be "Auto-detect proxy settings for this network".

This is very easy task to resolve, so I expect it could be introduced even to Fx
1.5 which aims to be corporate-ready.

I think it would probably be better to have a link to enable proxy autodetect on
the Server Not Found error page. I believe this is how IE does it. Or perhaps
try to auto-detect proxy settings if it can't load the home page.

I don't see what could be wrong with doing this. It doesn't break anything on my
end. That said, I don't know how this would affect others.

CC'ing darin and setting to New as I cannot find a dupe.

As to how IE does it, why not just go ahead and do the auto-detect and not run
into the problem to begin with, if auto-detect doesn't break anything of course ;)

MSIE's Server Not Found page only shows steps on how to enable auto-detection,
MSIE itself has the option set by default.

I think if netadmins have special wpad.example.net domain set they obviously
want the mechanism to be working. When the network doesn't have that domain name
it won't harm in any way and work as usual (i.e. no proxy).

The issue is that enabling auto-detect proxy settings may delay the amount of
time required to load the homepage for users who do not need to use a proxy to
connect to the network. Right now, we just load http://wpad/wpad.dat when asked
to auto-detect proxy settings, and we delay loading the user's homepage until we
get a response back from that wpad.dat request. If loading wpad.dat takes a
while to fail (slow DNS resolution), then it might result in a bad user
experience. So, I'm not sure what the right thing to do is.

How about we act as if we don't have any proxy settings set, fetching the home
page, etc as usual, and in the background fetch the wpad file; if we then find a
wpad file we can slide in those settings and automatically retry anything that
failed in the meantime. Would that work?

Yes, that might work. But, wouldn't it be odd if it caused the homepage to
reload? We went to great lengths in Firefox 1.5 to delay loading the homepage
until after the PAC file has been loaded because more often than not the PAC
file is needed in order to access the user's homepage.

Your comments made me to think of two possible resolutions.

1. Fetch wpad.dat in background and then retry any request in
"not-yet-connected" state, so if any file is already able to load without proxy,
let it finish, but all new and "not-yet-connected" to (re)load via proxy.

2. When starting Fx with fresh profile (and Import Wizard didn't import anything
about proxy settings), let the browser fetch wpad.dat file, if it successes -
set it as permanent, if it fails - set to direct.

I think turning this on by default has some impact on security.
In some setups (dhcp+ddns), people may simply not be aware about the whole wpad thing, or just think "I don't need it", so leaving the wpad name "free" in the zone, which will eventually result in somebody taking the name on the subnet...

Yeah, maybe this is the admin fault in the first place, and maybe IE allow this by default...

Plus, maybe some day, Firefox will be able to also autodetect proxy settings via dhcp; if this happens, will we need two different gui entries? What'll be the prefered (default) behavior?

Regards

> Plus, maybe some day, Firefox will be able to also autodetect proxy settings
> via dhcp; if this happens, will we need two different gui entries? What'll be
> the prefered (default) behavior?

i'm here regarding the use of DHCP for proxy config file URL autodetection
if ther's an existing bug please point me to it (i've been unable to find one so far)
as for how DHCP fits into the autodetection scheme, it's ment to be the primary method WPAD (web proxy auto detection) uses to determine where to find the configuration file, so it should all come under the same "auto-detection" banner, ie, no new setting should be needed

(In reply to comment #1)
> I think it would probably be better to have a link to enable proxy autodetect
> on
> the Server Not Found error page. I believe this is how IE does it. Or perhaps
> try to auto-detect proxy settings if it can't load the home page.
>
I'm setting up Mac computers running OSX 10.4.6, and the auto-detect network settings just doesn't work!
I'm in an educational setting where pac files are used.
Any suggestions?

(In reply to comment #11)
> (In reply to comment #1)
> > I think it would probably be better to have a link to enable proxy autodetect
> > on
> > the Server Not Found error page. I believe this is how IE does it. Or perhaps
> > try to auto-detect proxy settings if it can't load the home page.
> >
> I'm setting up Mac computers running OSX 10.4.6, and the auto-detect network
> settings just doesn't work!
> I'm in an educational setting where pac files are used.
> Any suggestions?
>

It works for me. Can you check if the URL http://wpad.example.com/wpad.dat is valid (replacing example.com with your own domain) ? That's what auto-detect is trying to load.

auto-detect is trying to load http://wpad/wpad.dat

John Vivirito (gnomefreak) wrote :

Changed to wishlist. Michael have you reported this upstream at https://bugzilla.mozilla.org/
Im thinking those settings should be applied before ubuntu builds it. If not can you please submit one upstream and give us the link.

Changed in firefox:
assignee: nobody → mozillateam
importance: Medium → Wishlist
status: Unconfirmed → Needs Info
Changed in firefox:
status: Unknown → Unconfirmed
Jun Wang (jhnjwng) wrote :

Michael
Thanks for your report. It was in upstream already.
https://bugzilla.mozilla.org/show_bug.cgi?id=310331
Change status to Confirmed.

Changed in firefox:
assignee: mozillateam → jhnjwng
status: Needs Info → Confirmed
Changed in firefox:
status: Unconfirmed → Confirmed
Alexander Sack (asac) wrote :

if bug is processed upstream we are "in progress"

Changed in firefox:
assignee: jhnjwng → mozillateam
status: Confirmed → In Progress
David Farning (dfarning) on 2007-02-24
Changed in firefox:
assignee: mozillateam → mozilla-bugs

After reading through these comments, I think there are some good points made on both sides of the argument, but I'd like to cast my vote with auto-detect by default on a new profile as Patryk Szczyglowski suggested.

I manage a large network where we don't have any direct control over the host computers and need to require all users to use the proxy server. As more users are using Firefox we've seen an increase in support calls because it's not the default. I think Patryk's suggestion is a nice compromise (a one time delay when first installing firefox should minimize the impact to the user and make my, and others in the same situation a lot happier)

Shouldn't the default rather be to do whatever the OS, resp. in Windows' case MSIE, has been configured to? See bug 218944 for making this possible under Windows. For Linux and Mac, this should even already be possible as of Firefox 3.0.

This conflicts w/ bug 416274.

Also, I think the current wpad implementation is not sufficiently robust to be the default, esp. since we don't have DHCP support yet.

Hello, bug 368194 is a duplicate as Jun Wang reported in the comments. I can not mark it as "duplicate", anyone can ?

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

Alexander Sack (asac) on 2008-10-31
Changed in firefox:
assignee: mozilla-bugs → nobody
status: In Progress → Triaged
Changed in firefox-3.0:
importance: Undecided → Wishlist
status: New → Triaged

what I did to fix it was after completely removing the program that created the problem (a proxy program to switch your IP) I edited the user.js and prefs.js found in C:\Documents and Settings\*your profile*\Application Data\Mozilla\Firefox\Profiles\*default folder* (mine is C:\Documents and Settings\Shawn\Application Data\Mozilla\Firefox\Profiles\25ejt7lb.default). before editing user.js and prefs.js MAKE COPIES of them in case something screws up. while firefox is closed right click on prefs and click edit. it should open in notepad, then go into Edit>Find (in notepad), type in "network.proxy.type" then hit "find next". make sure that the number after it is a 4 like this: user_pref("network.proxy.type", 4);
then go File>Save

then edit the user.js file, and do the same thing as in the prefs file. find "network.proxy.type" and make sure that there is a 4 after it.

Micah Gersten (micahg) wrote :

No more fixes will occur for Firefox 2.

Changed in firefox (Ubuntu):
status: Triaged → Won't Fix

This conflicts with bug 500983 (use system proxy settings as the default)

Changed in firefox:
importance: Unknown → Low

Useless because of bug 500983.

Changed in firefox:
status: Confirmed → Won't Fix
maravento (maravento) wrote :

tested in Firefox Quantum and works well (Only in version 63. It does not work in previous versions)

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

Other bug subscribers

Remote bug watches

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