Closed Bug 475008 Opened 16 years ago Closed 8 years ago

.part extension not removed from downloads without a filename (save link, data URI, trailing slash)

Categories

(Firefox :: File Handling, defect)

3.0 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: fabian, Unassigned)

References

()

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 When I link to the specified URL or Enter it, Firefox does nothing but downloads a .part file. It should open the file with the handler registered for text/calendar, which is the correctly provided mime-type in the url. Reproducible: Always Steps to Reproduce: 1. copy'n' paste url Actual Results: Firefox downloads the file, doesn't rename the .part file and doesn't open the default-application. Expected Results: Firefox should download the file, rename it correctly (remove the .part suffix) and open it using the registered default application.
I can reproduce this specific case (latest 3.1 on Linux), however when asking where to save the file its suggested name is already <random>.ics.part. If I just change the name I can save it normally.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Summary: Data-URIs aren't handled correctly → downloading from data: URIs appends .part extension to file name
I just found that my firefox correctly recognizes the file as "ICS-File". When I set the handler for ICS-Files to download the file, I get the download-dialog. When I set it to use ICal, the file is downloaded correctly, but nothing happens.
Is there some workaround for this?
This doesn't only happen for data URI's. Also "Save Link as..." is affected by this bug. This regressed somewhere on the 1.9.0 branch. FF2.0.0.20 works fine. We need a regression range here.
Severity: minor → normal
Summary: downloading from data: URIs appends .part extension to file name → .part extension not removed from downloads (save link, data URI)
Version: unspecified → Trunk
This regressed between the following builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040304 Minefield/3.0pre Checkins: http://tinyurl.com/cye8lc As what I can see bug 299372 has been caused this problem. Putting Justin on the CC list due to he has written the patch.
Version: Trunk → 3.0 Branch
Further steps are: 1. Load http://www.mozilla.org/projects/firefox/3.0pre/whatsnew/ 2. Open the context menu of the Mozilla logo 3. Click on the "Save link as..." menu item
It looks like the old codepath [going through saveURL() / getDefaultFilename() in contentAreaUtils.js] can determine the filename differently than the new codepath [going through DoContent() / GetFilenameAndExtensionFromChannel() in nsExternalHelperAppService.cpp]. GFAEFC() basically just uses nsIURL.fileName, and if that's empty it gives up (which presumably results in some other code creating a randomized filename?). getDefaultFilename, OTOH, has a series of fallbacks for the filename: document title, last directory name, hostname, or even just "index". This bug should manifest when saving any link that doesn't have a filename in the URL (data:foo, http://foo/, http://foo/bar/, etc.). Note that we fall back to the old code path when the browser.download.saveLinkAsFilenameTimeout fires, so if the server is slow you might see this work correctly. [And, as a potential workaround, you could set this pref 0, though that basically causes bug 299372 again.] So, we either need to make the caller smarter about providing a default file name to the nsExternalHelperAppService bits, or make nsExternalHelperAppService better at picking fallback filenames.
Summary: .part extension not removed from downloads (save link, data URI) → .part extension not removed from downloads without a filename (save link, data URI)
See also bug 367231.
Summary: .part extension not removed from downloads without a filename (save link, data URI) → .part extension not removed from downloads without a filename (save link, data URI, trailing slash)
Confirming still present in Firefox 3.5.8 on Mac OS X 10.5.8. The workaround is to do a Save As and then manually remove the .part from the filename. I encountered this when trying to download the "Business Edition Datasheet" from this page: http://pbworks.com/?srcWiki=pbworksweb7&apikey=3a218cad18647dd2dd338f5bc7d8b6ff22a63207&p=generic&w=biz+resources
Blocks: 622400
Still present on v.19 in Mac OS X 10.8.2
After loading data:text/calendar;charset=utf-8,BEGIN%3AVCALENDAR%0AVERSION%3A2.0%0AMETHOD%3APUBLISH%0ABEGIN%3AVEVENT%0ADTSTART%3A20090306T143000%0ADTEND%3A20090306T163000%0ASUMMARY%3APr%C3%BCfung%3A Algorithmen und Datenstrukturen 2%0ALOCATION%3AAudi. Max.%2C GM 1%0AURL%3Ahttp%3A%2F%2Fwww.wegweiser.ac.at%2Ftuwien%2Fhoersaal%2FAUDI.html%0ADESCRIPTION%3A%0AEinzel%0A(E186 Pr%C3%BCfung)%0AUID%3Atu-exam-186.170-20090306%0ASEQUENCE%3A0%0ADTSTAMP%3A20090023T155211Z%0AEND%3AVEVENT%0AEND%3AVCALENDAR in Firefox 19 beta 4 (build ID: 20130130080006) on a Mac OSX 10.8 machine I get the following: 1) If I want to open the file, it's opened with the CalendarFileHandler application, as expected 2) On the other hand, if I want to save the file, this is saved with .ics(1).part or .ics-1.part extensions. But when I try to open the file and select the Calendar application to open it, the file is opened as expected.
Please note that a workaround is available in v20. By specifying the "download" attribute I was able to get a correct file download in both Windows and Mac on Aurora 20.
Cannot reproduce with steps from comment 16 or comment 9 when using Nightly v23.0a1
Closing based on Comment 19 Please provide Firefox Version and updated STR if this should be reopened.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.