BuildID: 2000.03.13.03 When attempting to save a file, and returning to browse the web in the Mozilla window, the browser stops responding and the download halts. Window overwrites (like tooltips) are persistent over the Mozilla window and the d/l dialog. Reproducible: Always Steps to Reproduce: 1. begin downloading a file 2. browse the web in mozilla Actual Results: Browser locks up Expected Results: Save the file in a child process such that this could not happen (even if the process is zombied) or under a "download manager" that would allow continuing files implicitly and remember which ones failed.

Remarked critical since this should definitely be fixed before beta release. (hence keyword "beta1") Could one of the developers please confirm this. (I'll do some debugging on my own if you can't reproduce this bug.) Keyword "crash" added because the browser locks solid and must be closed from the parent or explicitly through kill (or equiv). In essence it crashes the browser. This bug prevents daily use, hence "dogfood", unless you don't download anything. Severity: Critical Keyword: crash beta1 dogfood

Impossible to test since 2000.03.14.16 doesn't run anymore.

is this a nscp_beta1_BRANCH build or trunk build. paulmac can you check this out?

Still a problem in nightly build 2000.03.16.05. Saving a file and then trying to browse (or do just about anything in the main window) causes the browser to lock for an indeterminite amount of time, as well as freeze the download. The main window doesn't refresh *anything* (including menus, tooltips, etc.), everything overwriting the main window remains persistent.

In this particular case we're hanging when image lib tries to download a file using OpenInputStream() then Read()'ing from it (see http://lxr.mozilla.org/seamonkey/source/gfx/src/nsImageNetContextSync.cpp#234 which is a blocking Read() call which blocks the UI thread and causes the event loop to be neglected). This causes everything to hang. I'm not sure why image lib is loading it's own URI's? Scott, should those loads just be going through the URI loader? If it needs to, it should be using the asynchronous api. Pam?

This looks like a dup of 31804. That's a problem with the beta branch; I think this problem exists on both the branch and trunk.

judson, to answer your question. No, the image lib shouldn't be going through the uriloader to load these image urls. The uri loader is intended to be used to initiate the top level url. If layout out that document causes other urls to be run (such as image urls, etc), those urls don't go through the uri loader. If you went through the uriloader we'd end up interrupting the original document url.

Bill and Jud are working on fix for this now. And yes, it's basically the same problem as bug #31804, but I want to leave this open and own it for now.

PDT would rather not have dup PDT+ bugs open. Closing this as a dup. Please verify *after* the dup has been fixed. Or if you prefer, don, reopen, and remove beta1/dogfood. *** This bug has been marked as a duplicate of 31804 ***

I'm reopening this in spite of potential bug 31804 duplication (this should be PDT-, now). Having separate threads for downloads is of interest, and slowing down the UI for the beta tree may be fine, but is an unsatisfactory solution in the long run. In particular, there exists the need for a UI-independent thread for the download. My first suggestion would be regularly polling the d/l thread for progress updates from the UI thread. The d/l thread should actually write progress updates to a file so that automated (206/html et al.) continuations become relatively trivial when possible, and the UI can poll those files for status updates. An integrated download manager is encouraged, highly. This has been slated for M16, but that is completely speculative on my part. (It isn't my place to impose like this, if it wasn't a valuable vested interest, given that I myself am not engineering Mozilla. But it is a vested interest.)

Summary/Status updated

depreciated. (apologies for spam)

- Per last comments, age of bug, and no reopen - Marking Verified/invalid. Please reopen if still a problem.