User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 It sometimes happens that when I try to use my onlinebanking account, the login page cannot be loaded yet doesn't timeout either. Mozilla keeps on trying to load that page. Meanwhile all other open tabs don't allow me to navigate either, it seems like the whole networking mechanism is in a deadlock situation. then click on "Online-banking". Reproducible: Sometimes Steps to Reproduce: 1. Go the start page: http://www.postbank.de (German) 2. Click on "Online-banking" 3. Wait and try to navigate in other tabs It only happens when there is a problem with that webpage. Actual Results: Nothing. Expected Results: Go on loading pages.

Sind you list the lack of UI response as the final step in your "Steps to Reproduce" I'm going to assume that you're actually complaining about the UI not responding in this bug. Therefore, marking as a dupe of bug 110718. If you really mean this bug to be about (sometimes) not accessing the reference URL, and believe this to be Mozilla's fault specifically, reopen the bug and clarify the report. (You can't have one bug that deals with two different problems.) *** This bug has been marked as a duplicate of 110718 ***

Further note: Could also be related to bug 76495 or bug 158429.

It has nothing to do with the UI which is still responding (I can open new tabs, scroll, etc.). As I wrote, it seems to have to do with networking since it looks like a deadlock in the socket code since there is no further data being processed, yet the broken URL doesn't time out. I can type in new URL's, click on links and nothing gets loaded anymore. Then I have to quit and restart Mozilla in order to continue browsing. This had already hapened with 1.0 so I was hoping that 1.1 would fix the problem, but it didn't.

I did some further testing with Socket Workbench (a Windows tool for monitoring socket connections). Here's what I did: - made SW listen on port 443 (https) - opened https://localhost with Mozilla 1.1 - in SW the connection got established, but of course SW didn't send back any confirmation so Mozilla was in a waiting state - as expected Mozilla didn't react on navigation requests anymore I ran the same test with standard http protocol on port 80 and didn't run into the deadlock problem.

WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 I never had Problems with that URI

Should be moved to HTTP Networking since it seems to be a networking problem.

hmm.. can someone confirm this bug using a recent nightly build? if you are able to repro the problem, then please enable these environment variables before launching mozilla to capture some networking information: set NSPR_LOG_MODULES=nsHttp:5 set NSPR_LOG_FILE=c:\http.log thx in advance!!

Well, the logfile doesn't show much, but here it is anyway (using a nightly from 09/05): 0[264330]: Creating nsHttpHandler [this=b092b0]. 0[264330]: nsHttpHandler::Init 0[264330]: nsHttpHandler::PrefsChanged [pref=(null)] 0[264330]: nsHttpAuthCache::Init 0[264330]: nsHttpHandler::Observe [topic="xpcom-shutdown")] 0[264330]: Deleting nsHttpHandler [this=b092b0] 0[264330]: dropping active connections... 0[264330]: dropping idle connections... 0[264330]: nsHttpAuthCache::ClearAll As I said before mozilla was blocked as long as the https connection didn't respond or got closed. I had to close the listening socket in Socket Workbench (which I made listen to port 443) in order to continue browsing in the other tabs.

this looks like bug 163605

reporter (Rainer): can you reproduce this bug with a recent nightly build of mozilla (newer than 20021016)? if so, please comment again with details. if not, please say so (because this is probably a dupe of the bug mentioned in the previous comment). thanks.

Just downloaded a recent nightly (2002112304), and the bug disappeared! It was still there in 1.2b which I had installed previously. Sorry for this late response, I was on vacation. Good work! :)

no problem, thanks for the response. verified.

no patch = not fixed

-> wfm

oops - should've spotted that. verified (as WORKSFORME).