Closed Bug 828202 Opened 8 years ago Closed 8 years ago

Proxy Auto Config - issue related to normalization of PAC file:// URIs causing system proxy configuration to fail

Categories

(Core :: Networking, defect)

18 Branch
All
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
firefox18 + verified
firefox19 --- unaffected

People

(Reporter: grubsi, Assigned: mcmanus)

References

Details

(Keywords: regression)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130104151925

Steps to reproduce:

I updated Firefox from version 17 to 18 on my Windwos 7 SP1 computer. After that I could not open any webpage anymore. Firefox infinitly tries to open the page, but the network sniffer showed me that no connection was established.
I tried to start Firefox without Add-Ons, reinstalled Firefox, resseted Firefox, but no change and the same also happened on other computers.


Actual results:

Thirst thought was it was the configured proxy configuration file (PAC-file) and I tried to change that to most easy version possible, but without success.
To figure out what's wrong I tried to change the proxy settings from use system proxy settings to use proxy configuration file to see if it is really the pac-file. Than everything worked again. So I tried to find out what is wrong and thought perhaps the system proxy settings in Internet Explorer are wrong. I disabled the proxy server so that only the configuration script is active, but no change in behaviour. I restored the proxy server settings and removed the configuration file and it worked again.

So system proxy settings with auto cofiguration script enabled are not working, without auto cofiguration script they are working!


Expected results:

The proxy settings should wor as before.
What is the exact URL to the pac file that you setup in windows ?
I'm not sure if bug 815783 fixed all cases on Firefox18, you may want to try a nightly build.
Component: Untriaged → Networking
Product: Firefox → Core
Flags: needinfo?(grubsi)
It's file://C:\Proxy\Config.pac
I already tried it from a different location, but it did not work. But the same value in the Firefox proxy-config URL field works.
Flags: needinfo?(grubsi)
Does it work if you change that to file:///c:/Proxy/Config.pac ?
No, I already tried that too.
I'm having problems with system proxy detection too. After updating to Firefox 18 "Use system proxy settings" no longer seems to work. If it's enabled and there is a proxy defined in "Manual proxy configuration" I get "The proxy server is refusing connections" error (e.g. https://www.google.com/). If I switch to manual mode, remove proxy entries and switch back to system mode, then sites begin to open as usually. I'm using Linux with KDE 4.9.
> I'm using Linux with KDE 4.9.

And proxy is disabled in system settings.
Pro, grubsi,

can you guys try an aurora build (FF 19).. There was a bug dealing with system proxies that has a real fix in FF19 but only a workaround patch in FF18 (due to the late timing of the fix). I would like to know if the code in FF19 works for you.

Thanks.
I've just tested, current Aurora doesn't have this bug
I tested Aurora too: It's working!
Attached patch patch 0Splinter Review
These are the patches from 815783 and 819902 that were not taken on 18 but are already included in >= ff 19.

I've sent them, on top of ff 18, to try so that we can have some builds the reporters here can confirm the fix with. If that works out I'll mark this approval-mozilla-release? and let the drivers decide what to do with it based on their review of the impact.

I'll also ask the folks in 828632 to test it as well so we can determine if that is a duplicate.
Attachment #700644 - Flags: review+
Builds will appear here based on FF18 with the prospective fixes included

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mcmanus@ducksong.com-4bd823c0f036

If Pro, grubsi (or anyone else) can confirm they work we can decide whether or not to take that on a FF18 update. Thanks!

The builds could take a while (anywhere from 30 mins to a few hours) to appear.
Flags: needinfo?(grubsi)
I just tested the version you created. It is working!
Flags: needinfo?(grubsi)
Attached image Error config
I've downloaded and tested this archive: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mcmanus@ducksong.com-4bd823c0f036/try-linux64/firefox-18.0.en-US.linux-x86_64.tar.bz2

And it's not working as expected. I'm attaching the screenshots to demonstrate the erratic behavior:
* sys-proxy-err.png: this config gives me error when trying to open any site (provided I don't have proxy at 127.0.0.1:8080)
* sys-proxy-ok.png: this config works correctly
Attached image Ok config
This may need to be entered as a new bug, but I am also experiencing issues with Firefox 18 and the Proxy Auto Config.

In my case, I am dealing with a 32-bit install of Firefox 18. Here is the relevant build information:

User Agent:
Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0

Build ID: 20130104151925

Whereas the other users reported that they were using the "Use System Settings" option, and that manually pointing to the Proxy Auto Config script fixed their issue, on my system neither setting works. It's as if the browser is no longer parsing the PAC. I can manually configure the proxy settings, but that isn't a viable long term solution as I work within a network environment where I need to access both intranet resources and internet resources, therefore the PAC is crucial for proper operation.

I have tried both Aurora and the patched FF18 linked to in the bug report with no success.  I have also reset my Firefox settings to default settings with no change in behavior.

If additional information is needed, please let me know.
(In reply to jdrosa from comment #15)
> This may need to be entered as a new bug, but I am also experiencing issues
> with Firefox 18 and the Proxy Auto Config.

> Whereas the other users reported that they were using the "Use System
> Settings" option, and that manually pointing to the Proxy Auto Config script
> fixed their issue, on my system neither setting works.

yes - totally different bug. Can you file it (and cc: mcmanus@ducksong.com).. in that new bug please include the contents of your pac file.. if you don't want to do that can you mail it to me please? (pmcmanus@mozilla.com)
(In reply to Pro from comment #13)
> Created attachment 700885 [details]
> Error config
> r
> And it's not working as expected. I'm attaching the screenshots to

screenshots show a config with system proxy selected but a disabled socks proxy also configured in failure case - the ok case has no socks proxy (with system proxy selected).

That's something else and probably shouldn't be tracked in this bug (it might even deal with runtime switching of options). I will try and repro it. The major issue seems to be ok so I think this patch can proceed.
Comment on attachment 700644 [details] [diff] [review]
patch 0

[Approval Request Comment]
Regression caused by (bug #): 769764
User impact if declined: Users with system proxy configurations, especially those with pac files using file:// urls to address them, risk total loss of network connectivity depending on the url. Even safe mode or a new profile won't help them.
Testing completed (on m-c, etc.): this patch has been on 20 + 19 for a few weeks. It was previously declined for 18 in favor of a workaround patch with the known risk that it might not address all uses cases and I think that's what we're seeing as 18 hits release. confirmed to solve reported problem in comment 12, and aurora (which contains this patch) is confirmed to solve reported field problems in comments 8 and 9
Risk to taking this patch (and alternatives if risky): at this point it seems better than what we have.
Attachment #700644 - Flags: approval-mozilla-release?
Blocks: 769764
Keywords: regression
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86_64 → All
Summary: System proxy settings issue with Firefox 18 → Proxy Auto Config - issue related to normalization of PAC file:// URIs causing system proxy configuration to fail
Duplicate of this bug: 829823
Windows XP

This problem appeared after updating to version 18 from version 17.1 .

Firefox don't open any website when running using normal user account. Running through admin privilege works normally.
Assignee: nobody → mcmanus
Attachment #700644 - Flags: approval-mozilla-release? → approval-mozilla-release+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Keywords: verifyme
I'm still trying to reproduce this (Windows 7 VM), but using a simple .pac file has been working on both 18 and 18.0.1.

grubsi, I'll keep digging for a little bit, but if I can't see the problem, would you mind trying the builds in:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0.1-candidates/build1/ release
 
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/19.0b2-candidates/build1/
beta

And making sure they work? Or would you mind sending me the .pac file you used and any other information necessary to recreate the problem?
(In reply to juan becerra [:juanb] from comment #22)
> I'm still trying to reproduce this (Windows 7 VM), but using a simple .pac
> file has been working on both 18 and 18.0.1.
> 
> grubsi, I'll keep digging for a little bit, but if I can't see the problem,
> would you mind trying the builds in:
> 
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0.1-candidates/
> build1/ release
>  
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/19.0b2-candidates/
> build1/
> beta
> 
> And making sure they work? Or would you mind sending me the .pac file you
> used and any other information necessary to recreate the problem?

juan - its actually the uri of the pac file, not necessarily the contents of it.. see comment 2
bug 829823 (a duplicate of this one) describes a way to reproduce the failure on Windows Vista with 18.0 -- including the .pac file and settings.

as noted above it's apparently the use of a file:// URL to identify the .pac file rather than the contents of the .pac file that causes the problem -- also in my case it happned only with "use system proxy settings" not when the URL was entered in Firefox's dialog box
I think I had misunderstood how this was setup, so I've retested with the following steps which make use of the system proxy settings (as opposed to specifying these in the Firefox preferences):

1. In a Win7 VM open the Control Panel and look for "configure proxy settings"
2. Click on LAN settings
3. Select "Use automatic configuration script"
4. Specify the file location such as file://User/mozilla/Desktop/proxy-sample.pac (see attached pac file I used)
5. Click OK and fire up Firefox and try browsing

Expected: happy browsing

Actual: In Fx18 you cannot connect to any page

It works in 17.0.1 and it now works in 18.0.1.

Please let me know if this is correct before I verify on 19.0b2. Sorry for the confusion.
Juan - comment 25, yes that's this bug

(In reply to juan becerra [:juanb] from comment #26)
> Created attachment 703116 [details]
> .pac file with some proxy server in Ukraine

:)
I tested the release in ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0.1-candidates/build1/win32/de/ and it is working fine.
This issue is verified on Firefox 18.0.1 (20130116073211), based on the STR from comment 25:
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0

I also checked that everything works as expected on Firefox 19 beta 2 (20130116072953), with the same STR from comment 25:
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Status: RESOLVED → VERIFIED
Given that we can't have a test for it in our tree, I would kinda like to see a Mozmill test for this particular issue. I'm fairly sure we can do that. I will file a new bug for it in a bit.
Flags: in-qa-testsuite?(hskupin)
QA Contact: manuela.muntean
Keywords: verifyme
This issue is also verified on Firefox 19 beta 6 (20130212082553), on the next machines:

1) Ubuntu 12.04 64-bit
2) Windows 7 64-bit
3) Windows 8 32-bit
4) Mac OSX 10.6.8
Removing my name from in-qa-testsuite flag for a better query.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.