31804 - open up another window/location while downloading freezes browser

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[sairuh (rarely reading bugmail)]

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

Comment 1

[sairuh (rarely reading bugmail)]

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.

Comment 2

[Paul MacQuiddy]

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.

Comment 3

[sairuh (rarely reading bugmail)]

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.

Comment 4

[Bill Law]

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.

Comment 5

[Bill Law]

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.

Comment 6

[Gagan]

I am sure there is a dup ->jud

Comment 7

[Judson Valeski]

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

Comment 8

[leger]

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

Comment 9

[Dan M]

why?

Comment 10

[Dan M]

  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?

Comment 11

[Judson Valeski]

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

Comment 12

[Doron Rosenberg (IBM)]

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.

Comment 13

[Peter Trudelle]

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?

Comment 14

[Judson Valeski]

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

Comment 15

[Warren Harris]

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.

Comment 16

[Peter Trudelle]

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

Comment 17

[Phil Peterson]

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

Comment 18

[don]

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

Comment 19

[Bill Law]

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.

Comment 20

[don]

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

Comment 21

[Bill Law]

Fix has been applied to the branch, also.

Comment 22

[Tom Everingham]

verified working on -
NT 2000032006
Mac 2000032006
Linux 2000032006