Closed
Bug 10613
Opened 25 years ago
Closed 24 years ago
Can't download files, downloading issues
Categories
(SeaMonkey :: UI Design, defect, P2)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
M18
People
(Reporter: cpratt, Assigned: law)
References
()
Details
(Whiteboard: [nsbeta2+])
Build ID: 1999072608
Platform: Mac OS 8.5 (only - Win32 and Linux are different)
To reproduce:
- Visit the above URL
- Try to download the Win32 Yahoo! Messenger (it's a *.exe file; the link reads
'Download for Windows 95/NT/98' and goes to http://www.zdnet.com/swlib/yahoo/)
Result: Nothing happens at all. The Location: control is not updated after
following the first link; the redirects don't seem to work, and the file is not
downloaded.
Expected result: The file is downloaded.
Comment 1•25 years ago
|
||
Not sure why these are being assigned to me...don, can you parcel out as
appropriate?
Accepting for M10. This code was recently changed, though; perhaps you could
try it now?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
It now works about as well on the Mac as it does on Windows/Unix. Still needs
some work re: setting creator and prompting for file name. These issues are
covered by other bugs.
Updated•25 years ago
|
QA Contact: phillip → elig
Comment 4•25 years ago
|
||
changing qa contact
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Summary: [PP] Mac - Can't download files → [PP] [DOGFOOD] Mac - Can't download files
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 5•25 years ago
|
||
The same problem (although probably a totally different bug ;) is still taking
place on this morning's Mac OS & Linux Commercial builds.
Specifically, after specifying the download directory, Seamonkey crashes after
completing the download. (Stack crawl to be enclosed shortly.)
Comment 6•25 years ago
|
||
Mac OS stack crawl:
PowerPC unmapped memory exception at 0D2F7368
Calling chain using A6/R1 links
Back chain ISA Caller
00000000 PPC 0DADFAE4
056E2540 PPC 0DADCC0C main+00194
056E24A0 PPC 0DADC65C main1(int, char**)+005D0
056E23B0 PPC 0D451D54 nsAppShellService::Run()+00018
056E2370 PPC 0D3FBFFC nsAppShell::Run()+00038
056E22F0 PPC 0D3FC744 nsMacMessagePump::DoMessagePump()+0003C
056E22A0 PPC 0D3FCA18 nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00174
056E2250 PPC 0D46D874 Repeater::DoRepeaters(const EventRecord&)+00030
056E2210 PPC 0D46E508 TimerPeriodical::RepeatAction(const EventRecord&)+
00048
056E21C0 PPC 0D46E064 TimerImpl::Fire()+00024
056E2180 PPC 0D491A0C nsGlobalWindow_RunTimeout(nsITimer*, void*)+00018
056E2140 PPC 0D491C24 GlobalWindowImpl::RunTimeout(nsTimeoutImpl*)+001A8
056E1EF0 PPC 0D47C078 nsJSContext::EvaluateString(const nsString&, void*,
nsIPrincipal
*, const char*, unsigned int, const char*, nsString&, int*)+00564
056E1DD0 PPC 0D47DC7C nsJSContext::ScriptEvaluated()+00024
056E1D80 PPC 0D48FC8C GlobalWindowImpl::CloseWindow(nsISupports*)+00054
056E1D20 PPC 0D48FBD0 GlobalWindowImpl::Close()+00030
056E1CE0 PPC 0D44632C nsWebShellWindow::Close()+002A0
056E1C00 PPC 0D56B87C nsCOMPtr_base::~nsCOMPtr_base()+00030
056E1BC0 PPC 0D151644 DocumentViewerImpl::Release()+51644
056E1B80 PPC 0D151B4C DocumentViewerImpl::~DocumentViewerImpl()+51B4C
056E1B00 PPC 0D29D3F8
nsXULDocument::SetScriptGlobalObject(nsIScriptGlobalObject*)+9D3
F8
Status: REOPENED → ASSIGNED
Whiteboard: [HELP WANTED]
Target Milestone: M11 → M12
Adding valeski to cc: list. Jud, my mac is pretty hosed so I never did test out
this new version of things there. I'm working on getting a build working, or
crashing :=(, but I wanted to alert you to this one.
Whiteboard: [PDT+] → [PDT+] Estimated date of completion: 1999/12/08
First, this bug has nothing to do with networking code.
The problem is that closing the download progress dialog is still tenuous, at
best. If you examine the code in downloadProgress.js that handles this, you'll
see this (currently):
try {
// Close the window in 2 seconds (to ensure user sees we're done).
window.setTimeout( "window.close();", 2000 );
} catch ( exception ) {
dump( "Error setting close timeout\n" );
for ( prop in exception ) {
dump( "exception." + prop + "=" + exception[ prop ] + "\n" );
}
// Bug prevents that from working, just close the window.
window.close();
// If that's not working either, change button text to give user a clue.
dialog.cancel.childNodes[0].nodeValue = "Close";
}
There was a bug that prevented the setTimeout call from working (since fixed?).
So, I added the catch clause that tried a straight "close." That failed, also
(for the same reason) and so as a last resort, I changed the button text to say
"Close" (rather than "Cancel").
Now, the setTimeout is working and on the Mac (but not Windows), this crashes
due to some object destruction ordering problem or something.
We should probably fix the problem (and I'll leave this bug open to prompt us to
do so). But to get to Dogfood, I think it will be prudent to alleviate the
symptom. So, I will change this .js so it doesn't do the setTimeout but instead
simply does a "window.close();". However, since that doesn't work
(nothing happens, which is another quirk that should now be addressed by this
bug, also), I will also add code to change the button text to "Close."
Here's the patch (which also has some other error handling code I've been
holding in my tree):
Index: downloadProgress.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/xfer/resources/downloadProgress.js,v
retrieving revision 1.2
diff -r1.2 downloadProgress.js
45a46,48
> case progId+";onError":
> onError( data );
> break;
214c217,224
< window.setTimeout( "window.close();", 2000 );
---
> //window.setTimeout( "window.close();", 2000 );
> // The above line causes crash on Mac (see bugzilla bug #10613).
> // As a workaround, change button text to "Close" and try a
> // simple close(). Note that the "close()" is also failing on the
> // Mac, thus the need for the fail-safe mechanism (changing the button
> // text).
> dialog.cancel.childNodes[0].nodeValue = "Close";
> window.close();
229a240,256
> }
>
> function onError( errorCode ) {
> // XXX - l10n
> var msg = "Unknown error";
> switch ( errorCode ) {
> default:
> break;
> }
> alert( msg );
> try {
> window.close();
> } catch ( exception ) {
> }
> dump( "Error closing dialog\n" );
> onStatus( "Error. Press Close button to close dialog." );
> dialog.cancel.childNodes[0].nodeValue = "Close";
I will get this code checked in and then change this bug to remove the PDT+ and
move it to M13.
Comment 10•25 years ago
|
||
Move to M13.
Whiteboard: [PDT+] Estimated date of completion: 1999/12/08
Assignee | ||
Comment 11•25 years ago
|
||
Removing [PDT+] (so PDT has a fresh look at this).
There are two problems here, both non-Dogfood/PDT+ (in my estimation).
1. On the Mac, a window.close() within a setTimeout crashes as the window is
closing. We currently avoid this crash by not doing the close on via
setTimeout.
2. window.close() fails (simply doesn't do anything) when invoked (indirectly)
via XPConnect; this on all platforms. The net result of this is that the
download dialog can't close itself (it changes it's button to "Close").
Both of these are problems with "window closing" (a chronic PITA) and/or
XPConnect.
My advice would be to change this bug's component to XPToolkit/Widgets and the
summary to address problem 1, and, to open a new bug for problem 2.
But I'll refrain from doing just that till I get some indication that there's a
consensus to do it. The PDT is empowered to make that determination, I should
think.
Updated•25 years ago
|
Whiteboard: [PDT-]
Comment 12•25 years ago
|
||
As long as the worst evidence of this problem is a dialog stuck on the screen
(i.e., you can download), PDT can call this a PDT-
Thanks,
Jim
Assignee | ||
Comment 13•25 years ago
|
||
*** Bug 21228 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Component: Browser-General → XPApps
Comment 14•25 years ago
|
||
adding self to cc list and updated component to XPApps. Eli, i'll take this one
off your hands if you want, as it also affects my test areas.
Assignee | ||
Comment 15•25 years ago
|
||
*** Bug 21550 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
QA Contact: elig → sairuh
Comment 16•25 years ago
|
||
Using the 1999122023 build, I can't reproducibly crash Seamonkey by downloading a
file. QA Assigning to sairuh.
Comment 17•25 years ago
|
||
hurm, i cannot repro this either (following cpratt's orginal recipe). tested
with the mozilla build (1999122111-m12 buts) on MacOS 9.0.
there was no crash. however, the progress dialog doesn't go away when
downloading is done (bug 21550, which was labelled a dup of this one). so i'd
rather keep this one open till that issue is resolved.
Summary: [PP] [DOGFOOD] Mac - Can't download files → [PP] Mac - Can't download files
Whiteboard: [PDT-]
Target Milestone: M13 → M15
Comment 18•25 years ago
|
||
Move to M15 for later investigation.
Updated•25 years ago
|
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Summary: [PP] Mac - Can't download files → Can't download files, downloading issues
Comment 19•25 years ago
|
||
since there are dup'd bugs that occurred on other platforms, am updating the
summary and OS fields.
Comment 20•25 years ago
|
||
Mozilla crashes (when downloading nightly builds from mozilla.org). WinNT 4 SP6A
Comment 21•25 years ago
|
||
when i download files, the download status dialog now goes away when it has
finished the download. has there been a particular fix checked in that did this?
tested (from context menu) the following at http://www.tcp-ip.or.jp/~s-iga/
Save page as
Save frame as
Save link as
Save image as
tested on the 3 main platforms:
linux, comm: 2000-01-20-08
winNT, comm: 2000-01-20-08
mac, moz: 2000-01-20-08
Assignee | ||
Comment 22•25 years ago
|
||
Yes, I fixed that on Tuesday when I checked in JS code that reverted to the
auto-close behavior (after 2 seconds). It had previously been disabled due to a
crashing bug on the Mac and/or because it generated a JS exception and thus
didn't work.
Is there any interest in adding a checkbox to this dialog that says "Close this
dialog when download is complete" (checked by default)? That's about 10 minutes
work to make it work that way.
Reporter | ||
Comment 23•25 years ago
|
||
law, that's how IE does it, correct? I'd check with shuang/german to see what
they'd like to do. Personally, I'm all for just closing the download dialog when
it's completed, but it's really up to them, innit? Thanks!
Comment 25•24 years ago
|
||
Due to bug #38376 (mac only), this cannot be tested on a mac (the
filepicker cannot be launched from the 'unknown file type' dialog, so
no download can be initiated).
On linux and windows, this works fine (modulo bug #38245 on linux
where the dialog increases in size as the download progresses).
Depends on: 38376
Comment 26•24 years ago
|
||
Doh! Please swap 38245 for 38376 in the comment above.
Comment 27•24 years ago
|
||
Putting on [nsbeta2+] radar for beta2 fix. In case found to be still broken.
Whiteboard: [nsbeta2+]
Assignee | ||
Comment 29•24 years ago
|
||
This seems to be working now. I just downloaded yahoo messenger and started it
up. This is a very old bug so it was likely due to some old bugs dealing with
redirects that have long been fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 31•24 years ago
|
||
Verified downloading works from this site.
Linux: 2000062610
Win and Mac verified by Leger
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•