563169 - Use system proxy settings doesn't work on Windows

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Bryan]

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

[Ernst]

Confirmed on Vista 32-bit with Firefox 3.6.3.

Comment 2

[Mike]

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

[Eric Lawrence]

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

[inactivist]

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

[Jo Hermans]

(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

[Eric Lawrence (@ericlaw)]

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.

Comment 8

[Paul [:dew]]

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

[Claude Vocat]

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

[sgt_b2002]

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

[Claude Vocat]

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

[sgt_b2002]

(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

[Eric Lawrence (@ericlaw)]

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.

Comment 14

[Masatoshi Kimura [:emk]]

Attachment: Use WinInet function instead of reading registry

Comment 15

[Claude Vocat]

(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...

Comment 16

[Masatoshi Kimura [:emk]]

Attachment: 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.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 18

[Masatoshi Kimura [:emk]]

Attachment: Use WinInet function instead of reading registry

Removed runtime check and just assume WinInet is always available

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1100e41af4e6

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/1100e41af4e6

Comment 21

[Scoobidiver (away)]

Backed out from Beta: http://hg.mozilla.org/releases/mozilla-beta/rev/6f6d971cd873

Comment 22

[mndt]

I'm using Firefox 17 and the problem still persists.

Comment 23

[Masatoshi Kimura [:emk]]

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.

Comment 24

[Mihai Morar, (:MihaiMorar)]

WFM for FF 18b4 and Latest Nightly (18/12/2012)

Comment 25

[Oleg Marchuk]

FF18.0 - it does not work again :(

Comment 26

[Scoobidiver (away)]

(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

[mndt]

It is a shame, it should take 18 iterations of a browsing software to have such a simple bug fixed.