The default bug view has changed. See this FAQ.

Use system proxy settings doesn't work on Windows

RESOLVED FIXED in Firefox 18

Status

()

Core
Networking
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Bryan, Assigned: emk)

Tracking

(Blocks: 1 bug)

unspecified
mozilla16
x86
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox16 disabled, firefox17 disabled, firefox18 fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

The new 'Use system proxy settings' doesn't work in Firefox 3.6+. This setting appears in the Tools->Options->Advanced->Network->Settings (Connection Settings) dialog. My expectation of this setting is that Firefox would inherit proxy configuration from Windows e.g. the same proxy settings as Internet Explorer would use. This setting is supported and functional in Chrome and Safari browsers for Windows. 


Reproducible: Always

Steps to Reproduce:
1. Connect to a local network that requires an HTTP proxy for all web traffic
2. Configure Internet Explorer proxy e.g. http://proxy.mynetwork.net:8080 (see http://windows.microsoft.com/en-us/windows-vista/Change-proxy-settings-in-Internet-Explorer for details if necessary)
3. Open the Firefox Tools->Options->Advanced->Network->Settings (Connection Settings) dialog
4. Select 'Use system proxy settings' and click OK
5. Attempt to view an internet web page
Actual Results:  
Firefox is unable to load any internet web page through the proxy, although pages are available through IE or Chrome browsers (using system proxy settings)

Expected Results:  
I expected Firefox would use the same proxy settings (URL) as IE and successfully display any internet web page.

I initially encountered this symptom in 3.6 Beta 3, running on WinXP SP2. I have also confirmed this on Windows 7 and Firefox 3.6.3. You can read the Firefox Support Forums discussion I started on this topic at https://support.mozilla.com/en-US/forum/1/509979 for corroboration from a number of other users.

Comment 1

7 years ago
Confirmed on Vista 32-bit with Firefox 3.6.3.

Comment 2

7 years ago
Confirmed on Windows XP SP2 with Firefox 3.6.3.

Not only does the 'Use system proxy settings' not work, but I have a PAC file that is accessible only as an http:// URI.  If I use the file:// protocol then the PAC file is not processed.  This means that I must keep a Web Server running on my PC.

Comment 3

7 years ago
The suggestion in a related thread that the user should try typing "proxycfg -u" from a command prompt suggests that Firefox is using WinHTTP to get the proxy information instead of WinINET. WinINET's proxy settings (which are shown in IE's control panel) support more features than WinHTTP, including the ability to process a PAC file which is delivered via the FILE protocol. Additionally, the use of WinHTTP suggests that Firefox is unlikely to be aware of dynamic changes of the proxy at runtime (e.g. when the Fiddler web debugger registers and unregisters as the system proxy).

Comment 4

7 years ago
Confirmed in Windows Vista X64, FireFox 3.6.8.

BTW, ProxyCFG doesn't exist in Vista.  
http://wmug.co.uk/blogs/r0b/archive/2010/01/08/proxycfg-on-vista-and-win2008.aspx

Comment 5

6 years ago
(In reply to comment #3)
> The suggestion in a related thread that the user should try typing "proxycfg
> -u" from a command prompt suggests that Firefox is using WinHTTP to get the
> proxy information instead of WinINET. WinINET's proxy settings (which are shown
> in IE's control panel) support more features than WinHTTP, including the
> ability to process a PAC file which is delivered via the FILE protocol.
> Additionally, the use of WinHTTP suggests that Firefox is unlikely to be aware
> of dynamic changes of the proxy at runtime (e.g. when the Fiddler web debugger
> registers and unregisters as the system proxy).

Firefox is not using WinHTTP or WinINET. It's reading the information from the registry.

Comment 6

6 years ago
Reading the ProxyServer, ProxyOverride, and ProxyEnable keys is straightforward, but that only gets you part of the way there. To fully support the system proxy, you need to parse the undocumented binary blobs under the Connections key, and since those are only freshened by WinINET itself, they're not guaranteed to be up-to-date if you're simply reading the registry alone.

The proper fix here is to use the InternetQueryOption API.

Updated

6 years ago
Version: unspecified → 3.6 Branch

Updated

6 years ago
Duplicate of this bug: 632180

Comment 8

5 years ago
Would using the InternetQueryOption API fix the problem that firefox has with proxy exceptions not being read correctly while using system proxy settings?  And is there a bug for that?  I couldn't find one while searching around bugzilla.

Comment 9

5 years ago
We found a similar problem, where "use system proxy settings" does not work.

I found that Firefox seems to read the proxy settings from "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" in our case AutoConfigURL.

But if we have set Policy "ProxySettingsPerUser" to false -> HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings", Firefox dowes not find the proxy settings, and browsing fails.

--> Firefox should check the policy setting and read form HKCU or HKLM accordingly.

Comment 10

5 years ago
I'm also experiencing this issue in FF 13 and Windows 7 Professional. I've detailed my testing conditions in the following forum topic:
https://support.mozilla.org/en-US/questions/928923

The long and short of it is that FF will not pick up the system proxy settings after a VPN connection is made or disconnected. IE must be launched and then closed before FF picks up the correct system proxy setting.

Comment 11

5 years ago
Sound like there is some caching of the proxy settings...

Did you try do change the caching ?

HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\
EnableAutoProxyResultCache=0 (DWORD)

Comment 12

5 years ago
(In reply to Claude Vocat from comment #11)
> Sound like there is some caching of the proxy settings...
> 
> Did you try do change the caching ?
> 
> HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\
> EnableAutoProxyResultCache=0 (DWORD)
Hi Claude, I added this registry entry, but the issue persists.

Comment 13

5 years ago
The EnableAutoProxyResultCache won't help because it has nothing at all to control what you're trying to control. That setting controls the behavior of Internet Explorer's WPAD script implementation which Firefox doesn't use at all.

If the Firefox team wants to fix this, what they really need to do is start calling the correct APIs rather than groveling the registry keys and hoping that they'll behave in some way that they obviously do not.
(Assignee)

Comment 14

5 years ago
Created attachment 631628 [details] [diff] [review]
Use WinInet function instead of reading registry
Assignee: nobody → VYV03354
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #631628 - Flags: review?(roc)
(Assignee)

Updated

5 years ago
Component: Preferences → Networking
Product: Firefox → Core
QA Contact: preferences → networking
Version: 3.6 Branch → unspecified

Comment 15

5 years ago
(In reply to Eric from comment #13)

The use of that API would be the best, as it would also consider dialup connections.
As i have seen in the code, Firefox today only checks the Registry settings for the current user, that means if the GPO is set to define the proxy settings per machine, FireFox does not find the good proxy settings.

As for now, FireFox uses the proxy script (.pac-file) by itself to identify the proxy to use. And some plugins do not use Firefox to ask for the proxy and fail to handle the .pac-file...
(Assignee)

Comment 16

5 years ago
Created attachment 631637 [details] [diff] [review]
Use WinInet function instead of reading registry

Unlike the registry, INTERNET_PER_CONN_AUTOCONFIG_URL may have the value even if the PAC is turned off.
Attachment #631628 - Attachment is obsolete: true
Attachment #631628 - Flags: review?(roc)
Attachment #631637 - Flags: review?(roc)
(Assignee)

Updated

5 years ago
Attachment #631637 - Attachment is patch: true
Comment on attachment 631637 [details] [diff] [review]
Use WinInet function instead of reading registry

Review of attachment 631637 [details] [diff] [review]:
-----------------------------------------------------------------

jmathies or Brian Bondy might be better reviewers.

::: toolkit/system/windowsproxy/nsWindowsSystemProxySettings.cpp
@@ +39,5 @@
>  {
> +    // Make sure wininet is available on the system.
> +    if (!sDLL) {
> +        sDLL = LoadLibraryW(L"wininet.dll");
> +        NS_ENSURE_TRUE(sDLL, NS_ERROR_NOT_AVAILABLE);

Is there any version of windows that doesn't include wininet.dll?

I'm actually confused. What's the point of this LoadLibraryW since we're already linking directly to wininet?
(Assignee)

Comment 18

5 years ago
Created attachment 631753 [details] [diff] [review]
Use WinInet function instead of reading registry

Removed runtime check and just assume WinInet is always available
Attachment #631637 - Attachment is obsolete: true
Attachment #631637 - Flags: review?(roc)
Attachment #631753 - Flags: review?(jmathies)
(Assignee)

Updated

5 years ago
Blocks: 621429

Updated

5 years ago
Attachment #631753 - Flags: review?(jmathies) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/1100e41af4e6
Flags: in-testsuite-
Keywords: checkin-needed
Target Milestone: --- → mozilla16
https://hg.mozilla.org/mozilla-central/rev/1100e41af4e6
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Depends on: 771115
Depends on: 774242
Depends on: 787757

Comment 21

5 years ago
Backed out from Beta: http://hg.mozilla.org/releases/mozilla-beta/rev/6f6d971cd873
status-firefox16: --- → disabled
Target Milestone: mozilla16 → mozilla17
Target Milestone: mozilla17 → mozilla16

Comment 22

4 years ago
I'm using Firefox 17 and the problem still persists.
(Assignee)

Comment 23

4 years ago
This was backed out from Firefox 17, not only Firefox 16.
https://bugzilla.mozilla.org/show_bug.cgi?id=787757#c35
@mndt: Please wait until Firefox 18 or try beta. Sorry for the inconvenience.
status-firefox17: --- → disabled

Updated

4 years ago
status-firefox18: --- → fixed
WFM for FF 18b4 and Latest Nightly (18/12/2012)

Comment 25

4 years ago
FF18.0 - it does not work again :(

Comment 26

4 years ago
(In reply to Oleg Marchuk from comment #25)
> FF18.0 - it does not work again :(
Please, file a new bug. This one is fixed.

Comment 27

4 years ago
It is a shame, it should take 18 iterations of a browsing software to have such a simple bug fixed.
(Assignee)

Updated

3 years ago
Depends on: 1004960
You need to log in before you can comment on or make changes to this bug.