Closed
Bug 31637
Opened 25 years ago
Closed 25 years ago
Saving files Locks browser (Thread D/L Manager)
Categories
(Core Graveyard :: Tracking, enhancement, P3)
Tracking
(Not tracked)
VERIFIED
INVALID
M17
People
(Reporter: bmh_ca, Assigned: don)
Details
(Keywords: crash, Whiteboard: Locking fixed ala bug 31804; D/L's not threaded off UI)
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.
Reporter | ||
Comment 1•25 years ago
|
||
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
Reporter | ||
Comment 2•25 years ago
|
||
Impossible to test since 2000.03.14.16 doesn't run anymore.
Depends on: 31901
Comment 3•25 years ago
|
||
is this a nscp_beta1_BRANCH build or trunk build.
paulmac can you check this out?
Assignee: chofmann → don
Reporter | ||
Comment 4•25 years ago
|
||
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.
No longer depends on: 31901
Priority: P3 → P2
Comment 5•25 years ago
|
||
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Comment 7•25 years ago
|
||
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.
Priority: P2 → P1
Target Milestone: M14
Comment 9•25 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 10•25 years ago
|
||
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.)
Reporter | ||
Comment 11•25 years ago
|
||
Summary/Status updated
Severity: major → enhancement
Priority: P2 → P3
Summary: Saving files Locks browser → Saving files Locks browser (Thread D/L Manager)
Whiteboard: Locking fixed ala bug 31804; D/L's not threaded off UI
Target Milestone: M16 → M17
Reporter | ||
Comment 12•25 years ago
|
||
depreciated. (apologies for spam)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
Comment 13•25 years ago
|
||
- Per last comments, age of bug, and no reopen - Marking Verified/invalid.
Please reopen if still a problem.
Status: RESOLVED → VERIFIED
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•