Closed Bug 490192 Opened 17 years ago Closed 17 years ago

Download Manager ignores "Always ask me where to save files" option; drops them all in system Temp directory, then attempts to open them.

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: magoldberg, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre (.NET CLR 3.5.30729) Beginning within the past 2 or 3 days, the nightly build's Download Manager has begun to ignore the "Always ask me where to save files" option. Instead, it drops all downloaded files into the system Temp directory, then attempts to open archives with the associated application (e.g., WinRAR; WinZip). This new behavior is highly undesirable. Reproducible: Always Steps to Reproduce: 1. Click on a link to begin a file download. 2. Instead of pausing to ask where to download the file, the Download Manager immediately starts the download, always directing it to the system Temp directory. 3. Upon completion of an archived download, the Download Manager opens the associated application and attempts to extract the contents. Actual Results: I next stopped the associated application from opening the archive, used the Download Manager's "Open Containing Folder" function to access it, then moved it to my desired location. Expected Results: When I first began the download process, the Download Manager should have paused and asked where to download the file, waited for a response, downloaded it to the desired location, then closed with no further action.
Version: unspecified → 3.5 Branch
Version: 3.5 Branch → Trunk
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre I see the file picker.
Component: General → Download Manager
Product: Firefox → Toolkit
QA Contact: general → download.manager
Different from bug 490202. An unrelated problem.
Clarification: Under "Steps to Reproduce," I should have written "Click on a link *within an email* to begin a file download."
Do you mean an e-mail attachment? This works normally here. Maybe the problem is caused by an extension? Please try safe-mode to find out. Or by a profile corruption? Try a new profile. http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
Ria, I just tried it in Safe Mode. The result was the exact same anomalous behavior. The link is not in an attachment, but within an ordinary email. It links directly to a RAR file (latest beta version of another program I'm testing -- an ongoing project with new releases every few days). Since FF is my default browser, clicking the link opens a blank tab in FF. Normally, it pauses at that point and waits for me to select a destination directory (as expected, since I have selected the "Always ask me where to save files" option). Instead, for the last few nightly versions of FF, it has been dropping the download into the system temp directory, then attempting to open it in WinRAR.
Just tried the new FF 3.5b4 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)). Result: same anomalous behavior as with the 3.6a1 nightly.
I tested also the link in an e-mail but everything is working as expected.
Very strange. I can't explain the difference, though. All I can do is report what I have observed. As I mentioned above, this behavior started within the past few days, but unfortunately I did not note the exact build where it began. Until then, the Download Manager would drop the file where I directed, then close.
I'd say: either an add-on, or a corruption in the profile, downloads.sqlite, and deleting the file should help, but since you already tried safe-mode and a new profile this can't be the case. So maybe a clean installation would help. First delete the Mozilla Firefox folder in Program Files manually, then reinstall.
(In reply to comment #10) > First delete the Mozilla Firefox > folder in Program Files manually, then reinstall. Sorry, if you're using Minefield or Shiretoko the name of the folder maybe called Minefield or Shiretoko (don't delete the wrong one) :).
I've already tried it on both the latest 3.6a1 nightly and the fresh, new installation of 3.5b4, and tried them both in Safe Mode, too. Makes absolutely no difference. I'll send you a copy of the link I've been using for the testing. Please try it and see how the download works for you. (It's 6.4 Mb --- the latest beta version of The Bat! --- not secret or anything:-)
Hey Morton, first I see this: http://img207.imageshack.us/my.php?image=downloaddialog.jpg and after confirming this: http://img207.imageshack.us/my.php?image=filepicker.jpg and I found the file in the intended folder. Can you go to C:\Documents and Settings\username\Application Data\Mozilla\Firefox\Profiles\e3sb2pva.default\ and delete the file downloads.sqlite?
OK, I deleted downloads.sqlite, then opened both Minefield (3.6a1) and 3.5b4 one at a time in Safe Mode. Set each to be default browser, then clicked the link. No difference --- same as before (except, of course, the download list was empty when I first looked). The pictures you sent are exactly like what I used to see before this started --- and what I'd like to see again :-) What else would you like me to try?
downloads.sqlite doesn't store the settings that control the opening behavior. You want to look at mimetypes.rdf
As of 20090501 build of Minefield 3.6a1pre, problem is not fixed.
See Bug 490644. Maybe the two bugs are related in a way?
Very interesting, but seems only distantly related. In this case, the save dialog never appears at all, yet the download proceeds anyway to a location of the Download Manager's choosing. Only common thread between these bugs appears to be Windows XP.
I just found that unbeknownst to me, another application -- probably WinRAR -- had altered the handling of RAR and ZIP files so that they would not be saved, but instead would be opened by their associated applications. I manually set both filetypes to "save file" and tested by re-downloading one of the RAR files through a hyperlink in an email. Mystery solved. Everything now works normally. Closing the bug report.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.