Open Bug 345311 Opened 18 years ago Updated 2 years ago

Content-Disposition is ignored on download retry

Categories

(Toolkit :: Downloads API, defect, P3)

defect

Tracking

()

People

(Reporter: u39892, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 When restarting a download, the Content-Disposition header is ignored, and filename is based on the URL instead. Reproducible: Always Steps to Reproduce: 1. Go to http://bowmore.dcs.st-andrews.ac.uk/mms/DownloadTest 2. Click cancel on the download 3. Click restart on the download Actual Results: A new download, with the file name "Download.htm" appears Expected Results: File name should stay as "dsl-3.0.iso"
Version: unspecified → 2.0 Branch
Might be related to bug 299372.
This bug seems to be present in build: 2006072103 (latest nightly build). This should probably be confirmed, but I don't have "canconfirm" privileges, yet.
This problem continues to appear in newer nightlies. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060727 BonEcho/2.0b1 right now as I speak.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 356086
This happens because getDefaultFileName() prefers using the filename from the URI over the default filename that was passed in to saveURL(). So when saveURL is called from onDownloadRetry, the passed in filename is ignored. (As a sidenote, onDownloadRetry passes a nsILocalFile object to saveURL instead of a string, which is what it expects. Good thing that argument is ignored! :/) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/downloads/content/downloads.js&rev=1.55&mark=445,446#440 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/contentAreaUtils.js&rev=1.85&mark=838-840,858#809 I don't think this depends on bug 356086, because the download retrying code no longer has access to the original channel. It has access to the original filename, it just doesn't use it correctly.
No longer depends on: 356086
OS: Windows XP → All
Hardware: PC → All
Attached patch incomplete patch (deleted) — Splinter Review
This fixes it, but I'm not sure that it correctly handles all cases. (the testcase in comment 0 is 404, by the way)
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Firefox 3 alpha1
Version: 2.0 Branch → Trunk
Test case resurrected, sorry about that.
Target Milestone: Firefox 3 alpha1 → ---
Product: Firefox → Toolkit
Is this bug still present?
Assignee: gavin.sharp → nobody
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: