Closed Bug 10613 Opened 25 years ago Closed 24 years ago

Can't download files, downloading issues

Categories

(SeaMonkey :: UI Design, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED

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.
Not sure why these are being assigned to me...don, can you parcel out as appropriate?
Assignee: don → law
Component: RDF → Browser-General
Status: NEW → ASSIGNED
Target Milestone: M10
Accepting for M10. This code was recently changed, though; perhaps you could try it now?
Whiteboard: [HELP WANTED]
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.
QA Contact: phillip → elig
changing qa contact
Status: RESOLVED → REOPENED
Summary: [PP] Mac - Can't download files → [PP] [DOGFOOD] Mac - Can't download files
Resolution: FIXED → ---
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.)
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+]
Putting on PDT+ radar.
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.
Priority: P3 → P2
Target Milestone: M12 → M13
Move to M13.
Whiteboard: [PDT+] Estimated date of completion: 1999/12/08
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.
Whiteboard: [PDT-]
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
*** Bug 21228 has been marked as a duplicate of this bug. ***
Component: Browser-General → XPApps
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.
*** Bug 21550 has been marked as a duplicate of this bug. ***
QA Contact: elig → sairuh
Using the 1999122023 build, I can't reproducibly crash Seamonkey by downloading a file. QA Assigning to sairuh.
Depends on: 21550
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
Move to M15 for later investigation.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Summary: [PP] Mac - Can't download files → Can't download files, downloading issues
since there are dup'd bugs that occurred on other platforms, am updating the summary and OS fields.
Mozilla crashes (when downloading nightly builds from mozilla.org). WinNT 4 SP6A
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
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.
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!
Move to M16 for now ...
Target Milestone: M15 → M16
Keywords: nsbeta2
Target Milestone: M16 → M17
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
Doh! Please swap 38245 for 38376 in the comment above.
Depends on: 38245
No longer depends on: 38376
Putting on [nsbeta2+] radar for beta2 fix. In case found to be still broken.
Whiteboard: [nsbeta2+]
Move to M18 target milestone.
Target Milestone: M17 → M18
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 ago24 years ago
Resolution: --- → FIXED
Updating QA Contact.
QA Contact: sairuh → tever
Verified downloading works from this site. Linux: 2000062610 Win and Mac verified by Leger
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.