open up another window/location while downloading freezes browser

VERIFIED FIXED in M14

Status

()

Core
Networking
P1
blocker
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Bill Law)

Tracking

(Depends on: 1 bug, {regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] Bill Law has a fix he's testing in the trunk, URL)

(Reporter)

Description

19 years ago
summary sez it all. occurs in the beta bits. i'll put in more details soon...!
(Reporter)

Updated

19 years ago
Keywords: dogfood, regression
(Reporter)

Comment 1

19 years ago
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.
Keywords: beta1
QA Contact: paulmac → sairuh

Comment 2

19 years ago
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.
(Reporter)

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
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.
(Assignee)

Comment 5

19 years ago
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.
Assignee: law → gagan
Component: XPApps → Networking
QA Contact: sairuh → tever

Comment 6

18 years ago
I am sure there is a dup ->jud
Assignee: gagan → valeski

Comment 7

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

Comment 8

18 years ago
Putting on PDT+ radar for beta1.  Reassigning to danm, need risk assessment on 
the fix.
Assignee: valeski → danm
Whiteboard: [PDT+]

Comment 9

18 years ago
why?

Comment 10

18 years ago
  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?
Assignee: danm → valeski

Comment 11

18 years ago
this happens w/ http downloads too (http://www.boulderdesign.com/Bin.zip). FTP 
isn't even in the loop. back over to danm.
Assignee: valeski → 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.

Comment 13

18 years ago
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

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

Comment 15

18 years ago
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.

Updated

18 years ago
Depends on: 26291

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] stumped but trying. help appreciated. not my area.

Comment 16

18 years ago
reassigning to warren since this does not involve windows., clearing whiteboard
comment.
Assignee: danm → warren
Whiteboard: [PDT+] stumped but trying. help appreciated. not my area. → [PDT+]

Comment 17

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

Comment 18

18 years ago
Bill Law has a fix he's testing in the trunk.
Whiteboard: [PDT+] → [PDT+] Bill Law has a fix he's testing in the trunk
(Assignee)

Comment 19

18 years ago
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.
Assignee: warren → law

Comment 20

18 years ago
jar, let Bill know when it's OK to check this into the branch.
Priority: P3 → P1
Target Milestone: M14
(Assignee)

Comment 21

18 years ago
Fix has been applied to the branch, also.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
verified working on -
NT 2000032006
Mac 2000032006
Linux 2000032006
Status: RESOLVED → VERIFIED

Updated

17 years ago
Depends on: 88583
You need to log in before you can comment on or make changes to this bug.