Closed
Bug 76325
Opened 24 years ago
Closed 23 years ago
Crash when main Moz window closes before download window
Categories
(SeaMonkey :: Download & File Handling, defect, P2)
SeaMonkey
Download & File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: doctor__j, Assigned: mscott)
References
()
Details
(Keywords: crash)
Attachments
(2 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010412
BuildID: 2001041212
When downloading files using Mozilla browser, closing the browser window while
leaving the download window alone, Moz will crash when you abort the download.
Reproducible: Always
Steps to Reproduce:
1. Go to the above URL (any other URL might do)
2. Try to download the PDF version of the "Anamorphic Widescreen DVD FAQ"
3. When it starts downloading the file, close the Mozilla window (just leaving
the download window alone).
4. Cancel the download and see it crash.
Expected Results: Aborting download should not cause a crash.
Comment 1•24 years ago
|
||
Confirmed in 2001041308 mac trunk.
I thought there was a similar bug, but I could not find it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•24 years ago
|
||
worksforme with win2k build 20010417.. (CVS debug and opt build)
Reporter: Many bugs are fixed in the last days. Can you try it again with a new
build ?
Trying to reproduce the bug using Win32 build 2001041704.
Result: Positive.
Bug still happened.
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
still crashing in 041704 Mac trunk.
see attachment for stacktrace.
changing to All/All, Networking.
Component: Browser-General → Networking
OS: Windows 98 → All
Hardware: PC → All
Comment 6•24 years ago
|
||
maybe this is a duplicate of (or dependant upon the fix of) bug #75626?
Assignee: asa → neeti
QA Contact: doronr → tever
The crash is happening in uriloader.
-->mscott
Assignee: neeti → mscott
Updated•24 years ago
|
Keywords: stackneeded
Keywords: nsenterprise
Comment 10•23 years ago
|
||
if this is crash AND nsenterprise, is someone going to target it?
also, does this happen outside of PDF?
Comment 11•23 years ago
|
||
adding nsenterprise+. Ben, not all crashes get fixed and nsenterprise is just a
nomination keyword so the two together don't mean much.
Assignee | ||
Comment 12•23 years ago
|
||
I couldn't reproduce this using a build from today on win32. (08/02/2001). Can
anyone else?
Comment 13•23 years ago
|
||
*** Bug 94609 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
mscott:
the dupe contains a Talkback ID if you need a new stack...
(Incident ID is TB33879296K.)
Assignee | ||
Comment 15•23 years ago
|
||
Here's teh stack trace from the bug marked a dup of this:
js_GetSlotThreadSafe [d:\builds\seamonkey\mozilla\js\src\jslock.c, line 511]
JS_InstanceOf [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1856]
JS_GetInstancePrivate [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1896]
args_enumerate [d:\builds\seamonkey\mozilla\js\src\jsfun.c, line 472]
js_PutArgsObject [d:\builds\seamonkey\mozilla\js\src\jsfun.c, line 249]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 1407]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1025]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 427]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 102]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 124]
nsDocLoaderImpl::FireOnStateChange
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1095]
nsDocLoaderImpl::doStopURLLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 700]
nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 553]
nsLoadGroup::RemoveRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 517]
nsHttpChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2156]
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 161]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
K
Comment 16•23 years ago
|
||
scott: I guess we are plussing nssenterprise? Okay, that makes more sense now.
Assignee | ||
Comment 17•23 years ago
|
||
the last talkback report with this stack trace was using buildID: 2001072700.
Marking works for me. If someone can reproduce this on a current build we should
re-open and see what we can do.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 18•21 years ago
|
||
Closing this one since it's been resolved long ago.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•