User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 I have configured the proxy using the Internet Settings of the system. All other browsers including Safari and Chrome is working fine with it. But in Firefox 4, I have to manually specify the proxy server in order to get things done. Reproducible: Always Steps to Reproduce: N/A Actual Results: Pages are not loading Expected Results: Firefox must use the system proxy settings in order to load the page
You didn't provide enough information. What are the proxy settings in IE: manual proxy, a pac file etc... ?
(In reply to comment #1) > You didn't provide enough information. > What are the proxy settings in IE: manual proxy, a pac file etc... ? Please see the attachment of proxy settings. I'm accessing Internet by overriding the proxy settings using Microsoft Proxy Client. My settings for Firefox 4 is to use "System Proxy Settings". But when I select this option Firefox is unable to connect Internet. I can also access Internet directly by Specifying Proxy settings. If I manually enter the proxy information, it works fine. But I'm using Proxy Client to override the default proxy restrictions and use my special permissions like GMail, Google Talk etc. Please let me know if I need to provide more details.
Hardware: x86_64 → x86
Version: unspecified → Trunk
Is it possible that the "Microsoft Proxy Client" is using an LSP ? Please run the command "netsh winsock show catalog >C:\lsp.txt" in a cmd window (without the quotes) and attach the file c:\lsp.txt to this bug using the "add an attachment" link above.
Please find the attachment. (In reply to comment #4) > Is it possible that the "Microsoft Proxy Client" is using an LSP ? > Please run the command "netsh winsock show catalog >C:\lsp.txt" in a cmd window > (without the quotes) and attach the file c:\lsp.txt to this bug using the "add > an attachment" link above.
They are using an LSP: "Microsoft Firewall Client Service Provider" We block some LSPs with Gecko2.0, this LSP could be affected
Component: Preferences → Networking
Product: Firefox → Core
QA Contact: preferences → networking
There are several companies are using the same proxy clients and this could negatively affect or forced to switch to other browsers like Google Chrome or Safari as it works perfect with them. Isn't it possible to revoke the restrictions?
Summary: System Proxy Settings are not identified → Blocked LSP: Microsoft Proxy Client / Microsoft Firewall Client Service Provider
I think this is Microsoft's problem. Their LSP should be categorizing itself appropriately (in fact, MS Firewall Client is one of the examples they use in the MSDN article about LSP categorization!) I see that you're running Microsoft Firewall Client 2004. Surely there's a newer version of this by now? I'd imagine that a newer version would fix this.
I'm not sure why this happens. All other browsers are working perfect in the system (Chrome and Safari) -Sarat (In reply to comment #9) > I think this is Microsoft's problem. Their LSP should be categorizing itself > appropriately (in fact, MS Firewall Client is one of the examples they use in > the MSDN article about LSP categorization!) > > I see that you're running Microsoft Firewall Client 2004. Surely there's a > newer version of this by now? I'd imagine that a newer version would fix this.
Because other browsers (to the best of my knowledge) don't set LSP categories on their executables.
Edit: mid-air/beaten to it, but might as well post anyway I guess! Sarat, a number of Firefox crashes are caused by buggy LSPs that are present on user's systems. Unfortunately all the user sees is Firefox crashing and has no idea it's actually caused by LSPs related to malware/badly written software, so blame Firefox. In bug 523410, all LSPs that do not declare themselves in the SYSTEM category were blocked intentionally in order to reduce the number of these crashes. The change only landed for Firefox 4, not the 3.x branches. LSPs that categorise themselves properly as SYSTEM, will not be affected. It sounds like your old version of the Firewall client does not do this; ie: doesn't even follows Microsoft's own MSDN advice page. This may have been fixed in a newer version of the Firewall client. Chrome/Opera have not done anything like blocking LSPs (yet), which is why they still work for you. IE does do something similar, when in low-rights mode, so would also be affected in certain scenarios. For more details on why the change was made in the first place, see bug 523410.
Actually, IE doesn't do anything with LSP categories. What happens is that many LSP's aren't written to do the right thing (e.g. only access parts of the OS that are accessible in protected mode, etc.) when an app runs in protected mode and hence won't work with IE when it runs in protected mode.
Kyle, using crashstats 20110105-pub-crashdata for all Firefox crashes (includes 3.6.x) I see a total of 1573 crashes with _PR_MD_SEND out of which there are only 46 with an os version of 6.0 and greater. It doesn't seem to be a problem worth trying to fix to me since we aren't seeing that many _PR_MD_SEND crashes with Vista and above on 3.6.x.
Talked with jst about this and he asked me to nominate so drivers van evaluate this since there doesn't appear to be many crashes with Vista and above on 3.6.x even though we don't block LSP's on 3.6.x. See comment #14 for more detail from crash stats (would appreciate it if someone verified my findings). Bug 621320 and bug 630481 are both cases similar to this bug report. iirc the way I implemented this will require a single line patch to remove our LSP categorization.
blocking2.0: --- → ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Okay - drivers argue for the importance of letting this firewall work over the unclear benefit of the LSP blocking in terms of crash reduction.
Assignee: nobody → robert.bugzilla
blocking2.0: ? → final+
Rob - can we get a patch today for this so that we can move towards RC post-haste?
Not a problem
Created attachment 515147 [details] [diff] [review] patch rev1
Attachment #515147 - Flags: review?(johnath)
Attachment #515147 - Flags: review?(johnath) → review+
Whiteboard: [hardblocker] → [hardblocker][can land]
(In reply to comment #19) > Created attachment 515147 [details] [diff] [review] > patch rev1 Hello, Is it possible for me to test this patch? How can I do it?
(In reply to comment #20) > (In reply to comment #19) > > Created attachment 515147 [details] [diff] [review] > > patch rev1 > > Hello, > > Is it possible for me to test this patch? How can I do it? It would be easiest by using tomorrow's nightly build... I'll give you details on what to do after I land the patch
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/e180004e766e
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(In reply to comment #22) > Pushed to mozilla-central > http://hg.mozilla.org/mozilla-central/rev/e180004e766e Thanks Robert. I shall check and update you on Monday morning (IST). I can test this only at my office as the proxy client is only available there.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #23) > (In reply to comment #22) > > Pushed to mozilla-central > > http://hg.mozilla.org/mozilla-central/rev/e180004e766e > > Thanks Robert. I shall check and update you on Monday morning (IST). I can test > this only at my office as the proxy client is only available there. No problem. You reopened this bug which you probably did unintentionally. In the future, please be careful not to do this when commenting in bugs.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
8 years ago
Duplicate of this bug: 621320
8 years ago
Duplicate of this bug: 630481
You need to log in before you can comment on or make changes to this bug.