336 bytes, text/html
Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=494893
Version: unspecified → 3.5 Branch
Done. Hope this helps, because this bug is pretty annoying.
I agree strongly with the need to fix this, but I'd like to disagree with the statement that versions prior to 3.5 work correctly. Versions prior to 3.0.10 work correctly based on my testing. (I make this point in case it helps accelerate finding and fixing the bug.)
I'm really wondering, when this bug will be assigned and fixed. It's so annoying, that Firefox became unusable. For my part, I've switched back to Opera. Opera is working perfectly.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: 3.5 Branch → 1.9.2 Branch
Store on local hd.
Interestingly with SSL-Proxy enabled FF 3 does not finish loading if you click on "Details"
We are having the same problem when you try to load a script through a non-existent domain such as: https://ssl.noexist.example.com/script.js Only a portion of the page will load if using SSL proxy. If proxy is turned off for SSL, the page will render fine, ignoring the missing script. So this appears to not only affect blocked scripts, but scripts with an erroneous URL as well.
CONFIRMing Compare 544979. From title: Reproducible with at least Privoxy and Squid. Privoxy bug: <https://sourceforge.net/tracker/index.php?func=detail&aid=2790091&group_id=11118&atid=460288> Privoxy 3.0.16 works around it by returning an empty page and 200 OK instead of blocking requests. (That doesn't change the fact that it's a bug in Firefox, though.)
Status: UNCONFIRMED → NEW
Component: Networking → HTML: Parser
Ever confirmed: true
QA Contact: networking → parser
Whiteboard: Regression in Firefox 3.0.9->3.0.10
Linked: Compare bug 544979
> I'd rather blame "Networking: HTTP" than "HTML: Parser" The network lib just reports the status code upwards (and does so properly, as you can see e.g. in XMLHttpRequest). It's the HTML parser / engine which does not continue. Probably, it simply doesn't handle the 'connection refused' and HTTP 4xx-errors correctly and decides to stall and wait infinitely. That's clearly faulty, because a errored fetch is never going to finish further.
You're probably right. This would also explain why the status line continues to display "Waiting for host ..." even if Firefox no longer has any connections open.
Based on comment 2, this seems a lot like bug 561536. Can anyone who sees this please check a current nightly of mozilla-central, 1.9.2, or 1.9.1 (or all three) to see whether those fix the issue for them? > The network lib just reports the status code upwards Are you sure? In the cases when this bug is encountered does it do that? One other thing that would be helpful here is an HTTP log from anyone who can reproduce the problem (ideally of as small a testcase as possible).
Component: HTML: Parser → Networking: HTTP
QA Contact: parser → networking.http
Indeed, this seems to have fixed it. The description also sounds like a DUP, so marking this bug a dup. Anybody who saw this, please also try for yourself, with a build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and report results here.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 561536
Fix confirmed, Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre
You need to log in before you can comment on or make changes to this bug.