Description of problem: On networks that require a proxy to access the web (and blocks all port 80 traffic), the new home page makes firefox hang for quite a while waiting for the tcp connection to time out before the window is mapped (and thus the user is able to set the proxy settings). Version-Release number of selected component (if applicable): On fedora 8 test 3. How reproducible: Always
confirmed for me too. And not just for proxied networks, it will also be very very slow to start if the user's home page server is down (even if started using 'firefox file://dev/null'. On networks where TCP SYN's are not rejected but silently dropped, firefox waits for the full timeout before even displaying a GUI. tonight, start.fedoraproject.org is offline. This means many users won't be able to start firefox in any reasonable amount of time.
Created attachment 274931 [details] firefox-failed-start.log ltrace -S -f on a firefox startup when the network drops SYN packets aimed at the browser's home page. No GUI is displayed for a very long time, if ever.
export NSPR_LOG_MODULES=nsHttp:5 export NSPR_LOG_FILE=firefoxhttp.log And then post a log from firefox after reproducing?
(In reply to comment #3) > export NSPR_LOG_MODULES=nsHttp:5 > export NSPR_LOG_FILE=firefoxhttp.log > > And then post a log from firefox after reproducing? Ok, here is what I've done to get this: 1. Do those exports. 2. Start firefox with a clean ~/.mozilla from the same shell prompt. 3. When the window finally appeared (~5 min later) I hit the stop button and the closed the firefox window. Will attach the log in a moment.
Created attachment 282891 [details] Log requested
If this issue turns out to still be reproduceable in the latest updates for this Fedora Core release, please file a bug report in the the upstream bugzilla located at http://bugzilla.mozilla.org in the particular component. Once you've filed your bug report to the upstream bugzilla, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking. Thanks in advance.
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test Firefox 3, available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping as the default in Fedora rawhide and provide feedback as to whether it still exists so we can file a ticket upstream to try to fix it in Firefox 3 before it is released.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. [This is a mass-closing request, if you think that this bug shouldn't be closed, please, reopen with additional information.]