User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Steps to reproduce: 4-5 days ago it still worked, so there seems to be a change in the networking component of Firefox nighlty build (V18). I tried to use all possibilities to define a proxy, but there seems to be no possibility to connect to the intranet via proxy or PAC file.

There seems to be an incompatibility between the add-on NoScript 2.5.6 (current version) and Firefox. After deactivation of NoScript, the proxy functionality is working.

Next time, you can try in safe mode to debug such add-on issues, it's very useful. :) https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

We had a change in the proxy area but I don't understand why it affects Noscript

Frank, I want to understand more precisely your bug report. I'm not quite sure what you're saying. What, in as much detail as you can muster, worked until a few days ago and then please describe the recent change in behavior that you get in the presence of noscript. that will help me test your report. thanks.

Frank, do the builds referenced by https://bugzilla.mozilla.org/show_bug.cgi?id=795905#c11 help?

Let me give a more precise report of the issue: I'm working in a corporate environment, where a proxy is necessary to get internet access. We are using a PAC file to define the proxy incl. the exception list, which is set in the Systems settings. So Firefox on my PC is configured using System settings "Use System Proxy Settings". Since approx. 1 week, no internet site is accessible any longer using this setting. Also putting in the link to the PAC file into "Automatic proxy configuration URL" or putting in the proxy directly into "Manual proxy configuration" didn't work any longer. So I tried to start Firefox without acivated Add-Ons, and everything worked again. After some tries I found out, that only deactivating the NoScript Add-on, was the solution for that. I also started Firefox with NoScript as only activated Add-on, and the internet access was not possible. So the combination of Firefox and NoScript was the reason that internet access was not possible. I also tried firefox-18.0a1.en-US.win32.installer.exe from the above mentioned directory /pub/mozilla.org/firefox/try-builds/mcmanus@ducksong.com-7a489bddf934/try-win32 but it still doesn't work.

Frank, did you report the issue to NoScript too? (gave this bug report) http://forums.informaction.com/viewforum.php?f=3

Is it a HTTP proxy or a SOCKS one?

OK, I tried the following with latest nightly (2012-10-04): 1) Created and loaded a new profile 2) Installed NoScript 2.5.6 and restarted the browser 3) Opened https://secure.informaction.com/ipecho in the browser and read my direct IP 4) Configured in Nightly's Advanced/Network/Connection Settings (manual proxy configuration) a SOCKS 5 proxy using a tunnel on an external SSH server of mine 5) Opened https://secure.informaction.com/ipecho in the browser and read my proxy server's IP 6) Manually configured 37.59.236.42:3128 (found on a public list) as a HTTP proxy for all the connections 5) Opened https://secure.informaction.com/ipecho in the browser and read "37.59.236.42" So it looks like "WORKSFORME". Could you confirm the steps above, also with PAC? If so, feel free to bring it to http://noscript.net/forum where we can try to narrow it down to a possible configuration specific or extensions conflict issue.

Yes, I reported the problem also to the NoScript developers. Topic: "Internet access using proxy is broken in Firefox 18 -Nighlty" I'm using a HTTP proxy to access the internet, not a SOCKS proxy

I did the following additional tests: 1) created and loaded a new profile 2)installed NoScript 2.5.6 and restarted the browser 3) configured Nightly's Advanced/Network/Connection Settings to use the systems settings (which is a PAC file) 4) opened www.google.de which didn't work 5) configured Nightly's Advanced/Network/Connection Settings (manual proxy configuration) with my company's proxy (HTTP proxy) 6) opened www.google.de which didn't work 7) installed IETab and restarted the browser 8) opened www.google.de with IETab switched to the IE rendering engine --> it worked So it looks like it's still "NOTWORKINGFORME" THe reported bug in the NoScript forum has currently the answer that it seems to be a Firefox issue......

(In reply to Frank Walburg from comment #11) > I did the following additional tests: > 1) created and loaded a new profile > 2)installed NoScript 2.5.6 and restarted the browser > 3) configured Nightly's Advanced/Network/Connection Settings to use the > systems settings (which is a PAC file) > 4) opened www.google.de which didn't work > 5) configured Nightly's Advanced/Network/Connection Settings (manual proxy > configuration) with my company's proxy (HTTP proxy) > 6) opened www.google.de which didn't work > 7) installed IETab and restarted the browser > 8) opened www.google.de with IETab switched to the IE rendering engine --> > it worked Just to be clear, I'd like to understand if it's a problem with NoScript preventing proxies from work or preventing PAC files from being retrieved. Your test above doesn't help deciding, because you didn't check whether manual proxy without NoScript actually work (you may be misconfiguring your manual proxy). Could you double check the above, to be sure that NoScript + manual proxy does not actually work for you (it apparently works for me)?

For the record, I tried also configuring the same Nightly clean profile + NoScript 2.5.6 to use "Automatic proxy configuration URL" = http://evil.hackademix.net/proxy.pac, whose content is function FindProxyForURL(url, host) { return "PROXY 37.59.236.42:3128; DIRECT"; } and it works as well: I can succesfully open https://secure.informaction.com/ipecho and the result is 37.59.236.42 as expected. Maybe something specific to your own PAC file?

Sorry that I didn't mention that: After creation and loading a new profile, and before installing NoScript, I tested the internet connection using Nightly's Advanced/Network/Connection Settings to use the systems settings and also with a manual proxy configuration to access www.google.de --> it worked So for me it seems to be a NoScript <-> Firefox problem.... I don't think that itr's a problem with the PAC file, as also the manual proxy configuration (using our company proxy) doesn't work Can I deliver some log information, that you can have a look at e.g. from NoScript ?

Sorry that I didn't mention that: After creation and loading a new profile, and before installing NoScript, I tested the internet connection using Nightly's Advanced/Network/Connection Settings to use the systems settings and also with a manual proxy configuration to access www.google.de --> it worked So for me it seems to be a NoScript <-> Firefox problem.... I don't think that itr's a problem with the PAC file, as also the manual proxy configuration (using our company proxy) doesn't work Can I deliver some log information, that you can have a look at e.g. from NoScript ?

(In reply to Frank Walburg from comment #15) > Can I deliver some log information, that you can have a look at e.g. from > NoScript ? It would be very helpful. Please check in your servers log whether your PAC file and/or proxy server gets hit by the browser, and look in the Error Console for any message remotely related to NoScript or failing request. BTW, I've also checked with a PAC file and a proxy located inside the LAN, to exclude ABE's LOCAL rule as a possible culprit, and it still works for me. On a side note, you may want to try anyway disabling ABE from Tools|Advanced and seeing whether it helps.

Thank you for the hint with ABE. I disabled ABE within the Advanced settings tab of NoScript, and internet access was possible with PAC file and also using manual defined proxy.

(In reply to Frank Walburg from comment #17) > Thank you for the hint with ABE. I disabled ABE within the Advanced settings > tab of NoScript, and internet access was possible with PAC file and also > using manual defined proxy. Then you should definitely see something about ABE in the Error Console, esp. in the "Messages" section. Could you please check?

yes, the following message is written: Security Error: Content at http://www.google.de/ may not load data from about:neterror?e=dnsNotFound&u=http%3A//www.google.de/&c=UTF-8&d=Firefox%20can%27t%20find%20the%20server%20at%20www.google.de..

I believe I've found the culprit thanks to the ABE logs sent me by Frank. It's probably a fallout from bug 769764, which removes the synchronous nsIProxyProtoclService.resolve() method and makes nsIProxiedChannel.proxyInfo unavailable, at least at the time http-on-modify-request observers are called. The before/after difference is nicely illustrated by the following script, which can be ran from a chrome environment scratchpad: let os = Cc['@mozilla.org/observer-service;1'].getService(Ci.nsIObserverService); let theTopic = "http-on-modify-request"; if (window._ho) os.removeObserver(window._ho, theTopic); os.addObserver(window._ho = { QueryInterface: function(iid) { if (Ci.nsIObserver.equals(iid) || Ci.nsISupportsWeakReference.equals(iid)) { return this; } throw Components.results.NS_ERROR_NO_INTERFACE; }, observe: function(subject, topic, data) { if (topic === theTopic && subject instanceof Ci.nsIHttpChannel) { if (subject instanceof Ci.nsIProxiedChannel) { Cu.reportError("nsIProxiedChannel.proxyInfo for " + subject.name + ": " + subject.proxyInfo + ", " + (subject.proxyInfo && subject.proxyInfo.type) ); } try { let proxyInfo = Cc["@mozilla.org/network/protocol-proxy-service;1"] .getService(Ci.nsIProtocolProxyService) .resolve(subject.URI, 0); Cu.reportError("Resolved proxyInfo for " + subject.name + ": " + proxyInfo + ", " + (proxyInfo && proxyInfo.type) ); } catch(e) { Cu.reportError(e) } } } } , theTopic, true); Just configure a proxy and open any HTTP URL, then watch the Error Console for error messages. In short, in Firefox 17 and below the presence of a proxy can be detected synchronously from http-on-modify-request observers, and this is used by NoScript's ABE module to take decisions about (possibly blocking) CSRF protection. Also, in order to respect user's privacy, NoScript is prevented from spawning any DNS request if a proxy is detected, unless direct DNS resolution explicitly allowed. In recent nightly builds, unfortunately, there's no apparent way to retrieve proxy info from http-on-modify-request observers, therefore ABE *in the specific DNS configuration used in Frank's LAN* gets confused and blocks the request. Anyway, even if complete breakage is probably uncommon (I couldn't reproduce it as seen above), the DNS privacy issue is huge nevertheless. Patrick, is there a way to ensure nsIProxiedChannel.proxyInfo is available at http-on-modify-request callback time? Calling asyncResolve() from there is quite a pain, considering that potential channel cancellation decisions must be taken before the request hits the network (CSRF is about requests, not responses).

Girogio, thanks for doing the research here. I need to research a couple things myself before suggesting a next step but I think this case actually highlights a reason why the change was made. You could never reliably do proxy detection synchronously at an early stage because the proxy system allowed a response of "unknown" for the type of the proxy. If you didn't resolve that unknown condition somehow then your code was open to bugs but that didn't seem to be a well understood property - so one of my goals here was to give you information you could rely on - even if it was later. (Before you could look at the proxy information as early as channel creation). what I need to research is exactly the timing of on-modify-request and whether or not that can be accommodated (or why it appears it is not right now).

(In reply to Patrick McManus [:mcmanus] from comment #21) > what I need to research is exactly the timing of on-modify-request and > whether or not that can be accommodated (or why it appears it is not right > now). http-on-modify-request happens immediately after channel creation, and before the http transaction starts. I'd be perfectly fine (actually, better off than ever before) if you could add a new notification ("http-on-request-ready"?) when all the resolutions are done but *before* the HTTP traffic hits the network, including proxy and DNS when applicable (i.e. when proxy settings don't mandate delegation), and even better to have the DNS record in use available somewhere (as a channel property?) so I don't have to replicate a caching mechanism myself (with all the reliability and complexity involved). Of course the ability to reliably cancel the request and having it never to hit the network would be crucial for the observers to be effective. It would probably not be enough yet, since I need to DNS-resolve the origin as well for cross-site requests (having access to *cached* DNS info some way would be great -- maybe by accessing the documentChannel on the originating docShell, if any?), but it would be nevertheless very helpful.

Giorgio, I've made a change so that the proxy resolution is available at o-m-r time. Thanks for the test case. Can you try one of these try builds and confirm? http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mcmanus@ducksong.com-cc277f290ed9/

Christian, I'm mildly concerned that this patch means setcookies() happens after on-modify-request instead of before it. I don't really see how that's a problem but I wanted to raise it.

What do you mean with setcookies? AddCookiesToRequest must happen before notifying the observers, but that still seems to be the case. SetCookie gets called after we get a response, so that's unrelated.

Also, two more notes: - this REALLY needs a test - please double-check that cancel() from a load group observer or from o-m-r will still prevent a network request from going out. I thought there used to be an if (mCancelled) check here that I don't see right now

(In reply to Christian :Biesinger (don't email me, ping me on IRC) from comment #25) > What do you mean with setcookies? AddCookiesToRequest I meant AddCookiesToRequest(), but you're right - I misread the diff. The ordering of that event isn't changed by the patch.

(In reply to Christian :Biesinger (don't email me, ping me on IRC) from comment #26) > Also, two more notes: > - this REALLY needs a test I'll see what can be cobbled up. > - please double-check that cancel() from a load group observer or from o-m-r > will still prevent a network request from going out. I thought there used to > be an if (mCancelled) check here that I don't see right now I think its still there http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#4423

(In reply to Patrick McManus [:mcmanus] from comment #28) > (In reply to Christian :Biesinger (don't email me, ping me on IRC) from > comment #26) > > Also, two more notes: > > - this REALLY needs a test > > I'll see what can be cobbled up. thanks! > > - please double-check that cancel() from a load group observer or from o-m-r > > will still prevent a network request from going out. I thought there used to > > be an if (mCancelled) check here that I don't see right now > > I think its still there > http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/ > nsHttpChannel.cpp#4423 Ah yes, so it is. Probably should be before the DNSPrefetch stuff...

Comment on attachment 669158 [details] [diff] [review] patch 0 The code looks good. But I'll wait with r+ until there's a test.

plus a xpcshell test

https://hg.mozilla.org/integration/mozilla-inbound/rev/6ee4101a85f3

Comment on attachment 669211 [details] [diff] [review] patch 1 [Approval Request Comment] Bug caused by (feature/regressing bug #): 769764 User impact if declined: a feature of no-script will be broken Testing completed (on m-c, etc.): on m-c. (19). pending confirmation from original reporter.. test case in xpcshell Risk to taking this patch (and alternatives if risky): small change to extension calling pattern might shake out bugs in add ons.. seems unlikely String or UUID changes made by this patch: none there will be a few edge cases related to 769764 to shake out in FF 18 as testing widens.

I tested the current nightly build version of Firefox 19 together with NoScript 2.5.7 add-on having ABE activated. Internet access using manual proxy or PAC file is now possible. Thank you all for solving this issue.

https://hg.mozilla.org/releases/mozilla-aurora/rev/1989adaaf7b4