summary sez it all. occurs in the beta bits. i'll put in more details soon...!

tested on winNT [2000.03.13.18-nb1b, opt comm]. to repro: 1. download a large file, eg, go to the above url. 2. when the Unknown File Type dialog appears, click Save As... 3. when the [native] File Save dialog appears, just save the file somewhere easy/obvious, like the desktop or the default directory. 4. while the file is downloading (the xp File Saving dialog is displayed), try to do any of the following: * Open Web Location * open a new browser window * click in the Location field to go to another page result: the browser freezes --as does the downloading. need to kill the netscape process.

sairuh, can you please try this on friday's 3/10 build and see if it happens also? would like to know if something checked in over the weekend has caused this. Thanks.

confirm: also occurs on linux [2000.03.13.19-nb1b, opt comm] and mac [2000.03.13.17-nb1b, opt mozilla]. note: best way to repro this is to select File > New Navigator Window while the file is downloading.

I tried this with a build from Friday and it failed the same way. I suspect it is a problem with deadlock in the file transport thread. One other thing I noticed: The "unknown content" dialog is not dismissed when you begin the download. It should be. This has been symptomatic of window open/close problems in the past, although that problem is perhaps unrelated to the apparent file transport deadlock situation.

I'm resetting the component to "Networking." Warren, this looks a lot like a bug we passed back and forth a couple of weeks ago re: "deadlock" when doing Save As... on file: URLs (although that one was Linux only). I noticed that trying to go to a different file: URL page while the download was underway didn't (usually) hang, but you didn't go to the page until the download completed. It's as if the second file: request is queued up. When that request is for a chrome: url (e.g., opening a new window) then it hangs.

I am sure there is a dup ->jud

*** Bug 31391 has been marked as a duplicate of this bug. ***

Putting on PDT+ radar for beta1. Reassigning to danm, need risk assessment on the fix.

why?

Jud and I have been talking about this bug and haven't reached any conclusions yet. So since there was no reason listed for giving it to me, I'm going to add observations Jud and I have traded that make me think it's his, and wait for it to be flipped back to me with, hopefully, some new knowledge. It seemed to me this problem may be related to the recent change in which ftp download messaging was moved to the UI thread from its own. The timing is about right. And the problem seems to have nothing to do with opening windows. My experience is that an attempted window open is delayed until the download has finished, which implies a possible problem with window opening. But neither can you start an ftp download and then browse to a new location in an extant browser window. In fact that hangs harshly. I'm just guessing: maybe the flood of FTP data events is swamping the UI event queue?

this happens w/ http downloads too (http://www.boulderdesign.com/Bin.zip). FTP isn't even in the loop. back over to danm.

bug 31791 has a similar problem - opening cnn.com with alt-L causes similar problems, typing into the url bar does not cause it. dunno if this is related though.

cc'ing valeski. Jud, what to you say to Daniel's contention that the browser can crash just following a link during a download? Wouldn't that tend to leave Window opening out of the picture?

it might. I'm not familiar with the window opening code. cc'ing warren, maybe the file transport is locking things???

What you have to do is break in the debugger when you get into the deadlock, and then look at each stack frame for each thread, and see what locks are being held. Usually some thread will be trying to enter a lock, and just waiting for it. You have to find the other thread that's holding it.

reassigning to warren since this does not involve windows., clearing whiteboard comment.

*** Bug 31637 has been marked as a duplicate of this bug. ***

Bill Law has a fix he's testing in the trunk.

I've checked in code on the trunk that seems to totally avoid the hang situations. After testing it out there, we can see about applying the patch on the branch as well. The fix rolled back (most of) the revision 1.15 changes which switched from using AsyncRead+(sync)Write to AsyncWrite+OpenInputStream. This means we are doing substantial I/O on the UI thread, but it only seems to cause an acceptable number of UI events to get lost/delayed. Basically, the UI gets a bit sluggish but no hangs occur. Long term, we're looking at taking the current logic and moving it to another thread (i.e., synchronous writes on a non-UI thread) with proxying of progress notifications back to the UI thread. This requires a bit more refactoring of the code than seems advisable for beta1. I'm reassigning this bug to me. I'll apply my patch to the branch when that's OK'd.

jar, let Bill know when it's OK to check this into the branch.

Fix has been applied to the branch, also.

verified working on - NT 2000032006 Mac 2000032006 Linux 2000032006