From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; IRIX IP32; en-US; rv:1.0rc1) Gecko/20020419 BuildID: 2002041910 Using "save link target as" from context menu for a link to a larger (> 50 kB or so) binary file fails to save anything (or saves just a fraction of the file). The file name dialog is fine and progress meter appears almost normally. There are unusual warning dialogs containing only the host name of the site. Reproducible: Always Steps to Reproduce: 1. Open the page 2. Select "Save Link Target As" from the context menu of one of the links, say net installer for Linux. 3. Select file name in dialog and click "Save". Actual Results: Progress meter appears for a while but disappears very soon. Several warning dialogs appear with the name of the site (ftp.mozilla.org). No file appears on the disk or just a very short fragment of it. Expected Results: The file should be saved normally. The bug is not specific to the Mozilla web site but appears everywhere I have tried. I could also reproduce it with clean profile.
Is there anything in the warning dialog other than the site name? This worksforme on Linux....
The title of the warning dialog says "Saving <filename>", but the text area contains just the name of the site. Clicking OK for one dialog usually brings out another and so on for some time.
I can also repeat this, but only with the optimised version of the browser. Built with debug it does the right thing.
Antti, are you using a proxy server? If so, see bug 144221. You might want to try with persistent connections turned off.
I am not using any proxies. Turning persistent connections off did not help either.
This seems to work fine for me in 1.1b (optimised).
Maybe related to "fails to save anything" Using Mozilla 1.1 (26.08.2002 release), the following occurred on two different Win NT4 (sorry, don't remember the SP-numbers atm, but I could look them up) boxes: - tried to save a ~120kb file "foo.zip", finished without any error - "foo.zip" did not appear in the windows explorer or DOS box - this could be interpreted as "fails to save anything" as reported - tried to save "foo.zip" again -> Mozilla crashed - saved "foo.zip" with IE to "foo1.zip" (worked), tried to rename "foo1.zip" to "foo.zip" -> got an error Message that a file named "foo.zip" already exists (ovwerwriting "foo.zip" did fail) - "del foo.zip" in DOS box -> "no such file.."-message Earlier releases (1.1-rcX, for example) did not have the same problem.
Hoo boy. This is going to be as bad as the cnn.com problem, which I foolishly added a duplicate bug, and am now cursed with getting infinite number of duplicates. I am unable to download java 1.4.1 sdk .sh (self-extracting shell script) using the Windows version of 1.4.1 Go to: http://java.sun.com/j2se/downloads.html Navigate to: Solaris 32 SPARC self extracting file. Try save target as file (or simply try to open the file) It fails. it succeeds easily on IE. I'm using 1.2b, so it has not been fixed in the most recent QA patch.
I have never seen the same behaviour on any other platform so I think this is probably a compiler bug related to the binaries SGI distributes. In any case a self-compiled (SGI MIPSpro compiler, either with or without optimisation) 1.2.1 works fine for me.
The use of the ' save link as ' menu actually crashes my browser under WXP Home
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030619 I don't think it's just an SGI bug. Take the following link as an example: http://www.powerware.com/Products/software/Powervision/sda_1.0_unix.tar Standard left-click brings up save dialog box and then shows "Saving xxxxK of 1400K" as it's downloading. It completes normally. However, right-click then "Save link target as" shows "Saving xxxxK of ????" and downloads at normal speed, but then when the download is finished it just sits there at "Saving 1400K of ????" and NEVER completes. This happens for both small (23K) and large (10MB) files from several sites, although I must add that I have seen this mainly with HTTP links, not FTP.
> In any case a self-compiled (SGI MIPSpro compiler, either with or without > optimisation) 1.2.1 works fine for me. is this then still a problem with SGI-contributed builds, or was your original report with a self-compiled build? In any case, if you can't reproduce this bug anymore, please mark it WORKSFORME.
I have only encountered the bug with SGI-contributed builds around 1.0 time. Later self-compiled versions have worked fine and also SGI-contributed 1.4 seems to work fine so apparently the issue has been solved somehow.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.