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

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[Fabian Zeindl]

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.

Comment 1

[Dave Garrett]

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.

Comment 2

[Fabian Zeindl]

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.

Comment 3

[Fabian Zeindl]

Is there some workaround for this?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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

Comment 8

[Justin Dolske [:Dolske]]

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.

Comment 9

[Jesse Ruderman]

I just ran into this when someone emailed me a text/calendar link:

http://www.meetup.com/The-South-Bay-Electronic-Music-Meetup-Group/calendar/ical/The+South+Bay+Electronic+Music+Meetup+Group/

Comment 10

[michalekx]

See also bug 367231.

Comment 13

[Eric Krock]

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

Comment 15

[David H]

Still present on v.19 in Mac OS X 10.8.2

Comment 16

[Manuela Muntean [Away]]

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.

Comment 17

[Manuela Muntean [Away]]

I get the same results as in comment 16, with the link from comment 9:  http://www.meetup.com/The-South-Bay-Electronic-Music-Meetup-Group/calendar/ical/The+South+Bay+Electronic+Music+Meetup+Group/

Comment 18

[Paul Hulett]

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.

Comment 19

[Iivari Äikäs [:orva]]

Cannot reproduce with steps from comment 16 or comment 9 when using Nightly v23.0a1

Comment 20

[Michelle Funches - QA]

Closing based on Comment 19
Please provide Firefox Version and updated STR if this should be reopened.