For privacy reasons, because I don't want to be tracked across the whole Web, I block .google-analytics.com. I do that in my HTTP proxy. On at least 2 websites, I cannot log in to my account using SSL. The page is loading forever, old page still displaying, not even a partial display of the requested page, and I see "Waiting for ssl.google-analytics.com..." in the status bar - forever, until I hit Stop or go elsewhere. I cannot log in to these websites. Affected: https://sourceforge.net/account/login.php http://www.sipgate.de Probably others, too
I file this as Tech Ev bug, but this should probably be fixes as Gecko bug. Gecko shouldn't block on non-critical parts of the page, including external JS files.
Compare bug 544979
Hmm, I block google-analytics.com using Adblock Plus 1.1.3 and have no issues with SSL sites at all! BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100208 Minefield/3.7a2pre (.NET CLR 3.5.30729) ID:20100208095921 ~B
According to http://osdir.com/ml/debian-bugs-dist/2010-04/msg05582.html Privoxy 3.0.16 should fix this problem. "Please package 3.0.16 as it fixes SF#2790091 "Firefox fails to render if https request for js is blocked". This bug/missing feature hinders rendering of websites like sourceforge.net, ubuntu.com, etc., because of privacyless trackers like google-analytics.com."
I may have a hint on the source of the problem, which I can clearly confirm with firefox-3.6.4, seamonkey-2.x on Linux and Windows. Since my upgrade to seamonkey-2 some time ago I noticed that some web pages stopped to load - a blank page was displayed (or old contents remains), the progress indicator is showing that the browser is waiting but nothing happens, there is no network traffic and there are no open network connections. Sometimes the last information on the status bar is something like "waiting for ssl.googlesyndication.com" and similar. Tracking this revealed that because my squid proxy setup blocks some sites like googlesyndication.com, doubleclick.net etc. by acls, when they are accessed by https instead of http, mozilla browsers (tried seamonkey and firefox) got stuck and there is no way loading a (SSL) web page referring to one of the blocked sites. Only removing the block or using another browser (Konqueror and IE work OK) allows to view the page. The problem may be caused by the error message squid sends over the line when a blocked page is requested which probably is not SSL encrypted. So the SSL code gots stuck, it even does not recognize that the TCP connection has been terminated and is waiting forever without a timeout for something. With seamonkey-1 this problem did not show up but latest versions had other encryption issues so I didn't try them lately. It may be a squid bug as well that the error message is encoded wrong but the browser should not get confused. My attempt to generate the bug by trying to load an non-ssl-page over https results in an ssl_error_rx_record_too_long error message so can't provide any other way to trigger the error except to use squid (currently 3.0.19 but this didn't make a difference) with an http_access deny acl to some ssl site. Accessing the blocked sites over http does not make any trouble. Seems to be same or similar issue as bugs #493704, #512374 and #544979.
I propose to close this meta bug. It is either a non Tech Evangelism bug due to a different behavior in Firefox (and if it's still the case, let's open a proper bug in the right component.) Or an evangelism bug for each individual site: If there are **still** any issues related to blocking related to contacting a Web site to fix an issue, please open a separate issue for each of them. If someone decides to reopen this specific bug, please provide HTTP traces with a detailed description and/or the exact setup to replicate the issue. Thanks.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Component: English US → Desktop
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.